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FOREWORD 

This  material  is  published  as  part  of  Contract  N00014- 
76-C-0732  with  the  Office  of  Naval  Research,  United  States 
Department  of  the  Navy,  entitled,  The  International  Purdue 
Workshop  on  Indus  trial  Computer  Systems  and  Its  Work  in 
Promoting  Computer  Control  Guidelines  and  Standards . This 
contract  provides  for  an  indexing  and  editing  of  the  results 
of  the  Workshop  Meetings,  particularly  the  Minutes,  to  make 
their  contents  more  readily  available  to  potential  users.  We 
are  grateful  to  the  United  States  Navy  for  their  great  help 
to  this  Workshop  in  this  regard. 


Theodore  J.  Williams 
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BACKGROUND  INFORMATION  ON  THE  WORKSHOP 

The  International  Purdue  Workshop  on  Industrial  Computer 
Systems,  in  its  present  format,  came  about  as  the  result  of 
a merger  in  1973  of  the  Instrument  Society  of  America  (ISA) 
Computer  Control  Workshop  with  the  former  Purdue  Workshop  on 
the  Standardization  of  Industrial  Computer  Languages,  also 
cosponsored  by  the  ISA.  This  merger  brought  together  the 
former  workshops'  separate  emphases  on  hardware  and  software 
into  a stronger  emphasis  on  engineering  methods  for  computer 
projects.  Applications  interest  remains  in  the  use  of  digi- 
tal computers  to  aid  in  the  operation  of  industrial  processes 
of  all  types. 

The  ISA  Computer  Control  Workshop  had  itself  been  a re- 
naming in  1967  of  the  former  Users  Workshop  on  Direct  Digital 
Computer  Control,  established  in  1963  under  Instrument  Society 
of .American  sponsorship.  This  Workshop  in  its  annual  meet- 
ings had  been  responsible  for  much  of  the  early  coordination 
work  in  the  field  of  direct  digital  control  and  its  applica- 
tion to  industrial  process  control.  The  Purdue  Workshop  on 
Standardization  of  Industrial  Computer  Languages  had  been 
established  in  1969  on  a semiannual  meeting  basis  to  satisfy 
a widespread  desire  and  need  expressed  at  that  time  for  devel- 
opment of  standards  for  languages  in  the  industrial  computer 
control  area. 

The  new  combined  international  workshop  provides  a 
forum  for  the  exchange  of  experiences  and  for  the  development 
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of  guidelines  and  proposed  standards  throughout  the  world. 

Regional  meetings  are  held  each  spring  in  Europe,  North 
America  and  Japan,  with  a combined  international  meeting 
each  fall  at  Purdue  University.  The  regional  groups  are 
divided  into  several  technical  committees  to  assemble  imple- 
mentation guidelines  and  standards  proposals  on  specialized 
hardware  and  software  topics  of  common  interest.  Attendees 
represent  many  industries,  both  users  and  vendors  of  indus- 
trial computer  systems  and  components,  universities  and  re- 
search institutions,  with  a wide  range  of  experience  in  the 
industrial  application  of  digital  systems.  Each  workshop 
meeting  features  tutorial  presentations  on  systems  engineer- 
ing topics  by  recognized  leaders  in  the  field.  Results  of 
the  workshop  are  published  in  the  Minutes  cf  each  meeting, 
in  technical  papers  and  trade  magazine  articles  by  workshop 
participants,  or  as  more  formal  books  and  proposed  standards. 
Formal  standardization  is  accomplished  through  recognized 
standards-issuing  organizations  such  as  the  ISA,  trade  asso- 
ciations, and  national  standards  bodies. 

The  International  Purdue  Workshop  on  Industrial  Computer 
Systems  is  jointly  sponsored  by  the  Automatic  Control  Systems 
Division,  the  Chemical  and  Petroleum  Industries  Division,  and 
the  Data  Handling  and  Computations  Division  of  the  Instrument 
Society  of  America,  and  bj'  the  International  Federation  for 
Information  Processing  as  Working  Group  5.4  of  Technical 


Committee  TC-5. 
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The  Workshop  is  affiliated  with  the  Institute  of 
Electrical  and  Electronic  Engineering  through  the  Data 
Acquisition  and  Control  Committee  of  the  Computer  Society 
and  the  Industrial  Control  Committee  of  the  Industrial 
Applications  Society,  as  well  as  the  International  Federa- 
tion of  Automatic  Control  through  its  Computer  Committee. 


INTRODUCTION 


The  Office  of  Naval  Research  of  the  Department  of  the 
Navy  has  made  possible  an  extensive  report  summary  and 
indexing  of  the  work  of  the  International  Purdue  Workshop 
on  Industrial  Computer  Systems  as  carried  out  over  the  past 
eight  years.  The  work  has  involved  twenty-five  separate 
workshop  meetings  plus  a very  large  number  (over  100)  of 
separate  meetings  of  the  committees  of  the  workshop  and  of 
its  regional  branches.  This  work  has  produced  a mass  of 
documentation  which  has  been  severally  edited  for  the  ori- 
ginal minutes  themselves  and  then  again  for  these  summary 
collections . 

A listing  of  all  of  the  documentation  developed  as  a 
result  of  the  U.S.  Navy  sponsored  project  is  given  in  Table 
I at  the  end  of  this  Introduction.  The  workshop  partici- 
pants are  hopeful  that  it  will  be  helpful  to  others  as  well 
as  themselves  in  the  very  important  work  of  developing 
guidelines  and  standards  for  the  field  of  industrial  computer 
systems  in  their  many  applications. 

In  their  review  of  the  several  types  of  industrial  com- 
puter languages  under  consideration  by  the  several  Workshop 
language  committees  the  attached  reports  on  presently  pro- 
posed or  recently  developed  languages  were  presented  to  the 
Workshop  and  published  in  the  several  Minutes.  They  are 
reproduced  here  to  document  the  state-of-the-art  against 
which  the  LTPL,  the  POL  translation  systems,  and  the  FORTRAN 
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and  BASIC  extensions  are  being  developed.  The  language 
comparison  document  of  LTPL-E  (Item  3 of  Table  I)  is  also 
important  here. 
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TABLE  I 

A LIST  OF  ALL  DOCUMENTS  PRODUCED  IN  THIS  SUMMARY 
OF  THE  WORK  OF  THE  INTERNATIONAL  PURDUE 
WORKSHOP  ON  INDUSTRIAL  COMPUTER  SYSTEMS 

1 .  The  International  Purdue  Workshop  on  Industrial  Computer 
Systems  and  Its  Work  in  Promoting  Computer  Control 
Guidelines  and  Standards , Report  Number  7 7 , Purdue  Labor- 
atory  for  Applied  Industrial  Control,  Purdue  University, 
West  Lafayette,  Indiana,  Originally  Published  May  1976, 
Revised  November  1976. 


2 .  An  Index  to  the  Minutes  of  the  International  Purdue 
Workshop  on  Industrial  Computer  Systems  and  Its 
Predecessor  Workshops , Report  Number  88,  Purdue  Labor- 
atory  for  Applied  IndusFrial  Control,  Purdue  University, 
West  Lafayette,  Indiana,  January  1977. 


3.  A Language  Comparison  Developed  by  the  Long  Term  Proce- 
dural Languages  Committee  - Europe , Committee  TC-T  oT~ 
Purdue  Europe , Originally  Published  January  1976,  Repub- 
lished October  1976. 


4 - 9 . Significant  Accomplishments  and  Documentation  of  the 

International  Purdue  Workshop  on  Industrial  Computer 

Systems . 

Part  I - Extended  Fortran  for  Industrial  Real-Time 

Applications  and  StudFes  in  Problem  Oriented 
Languages 

Part  II  - The  Long  Term  Procedural  Language 

Part  III  - Developments  in  Interfaces  and  Data 

Transmission,  in  Man-Machine  Communications 
and'  in  fire  Safety  and  Security  of  Industrial 
Computer  Systems 

Part  IV  - Some  Reports  on  the  State -of -the -Art  and 

Functional  Requirements  for  Future  Applications . 

Part  V - Documents  on  Existing  and  Presently  Proposed 

Languages  Related  to  the  Studies  of  the  Workshop 

Part  VI  - Guidelines  for  the  Design  o_f  Man/Machine  Inter- 
f aces  for  Process  Control 
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All  dated  January  1977. 

The  latter  seven  documents  are  also  published  by  the 
Purdue  Laboratory  for  A.pplied  Industrial  Control,  Purdue 
University,  West  Lafayette,  Indiana. 
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IN  I H( M)l  CTION 
FOR 

PROCOS  (Process  Control  Oriented  Software  System) 


(If  there  are  any  questions  or  comments  on 
these  documents,  please  let  us  know.  ) 


Problem  Oriented  Language  Working  Group 

Technical  Cmnmittee-on  Industrial  Computer 
Software  Standardization 

Japan  Electronic  Industry  Development  Association 

(JE1DA) 


WG  Chairman; 


Takashi  Tohyama 

/ ’ ~ 


Instrumentation  and  Control  Dept. 
Chiyoda  Chem.  Eng.  Const  Co.  . 
No.  1 580,  Tsuruni i 
Yokohama,  JAPAN 


1 . Introduction 

The  Problem  oriented  Language  (POL)  Working  Group 
developed  the  practical  software  design  quideline  through 
the  past  three  years  works 

The  products  of  this  working  are  summarized  the  following 
documents . 

(1)  PROCOS  I ser's  Manual 

(2)  PROCOS  Design  Specification 

The  meaning  of  PROCOS  is  Process  Control  Oriented  Software 
System 

This  PROCOS  is  designed  to  apply  process  data  processing  and 
control,  and  to  utilize  past  experience  and  expected  new  hard- 
ware/soft ware  technology.  This  PROCOS  is  developed  to 
utilize  data  base  handling  and  language  processing  capability, 
and  these  capabilities  are  to  add  the  flexibility  and  the 
reliability  on  software  system. 

To  use  PROCOS,  the  following  features  are  given. 

(1)  Reduce  software  development  cost 

(2)  Make  accurate  and  reliable  system 

(3)  Make  good  documentation 

(4)  Rasy  modification 

But,  there  are  required  more  improvements  to  make  more 

efficiency  and  compact  package.  Besides,  there  are  needs 
to  more  application  oriented  functions.  To  prepare  this 
PROCOS  is  the  first  step  to  make  progress  in  future  and  to 
use  for  education. 


’■“'Wl 
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PltOC'OS  df-.iL'H  cuncepm 

2 .1  Scope  of  PROCOS 
• 

PROCOS  ;s»  ilie  si »! i ware  p;u  kage  system  to  u.si  fill 
in  the  form  (I'll-  ) lor  un’in^  application  pt-ci fixa- 
tion and  procedure  PUCK  OS  consists  ol  the 
follow  me  twelve  forms. 


(1) 

Process  Variable  Input  Processing 

(2) 

Process  Variable  Monitoring 

(3) 

Process  Constant  Definition 

(4) 

Process  Variable  Output  Processing 

(5) 

Calculate  Processing 

(G) 

l)J)C  Processing 

(7) 

Logical  Variable  Processing 

(8) 

Status  Change  Detecting 

(9) 

Digital  Output  Processing 

(10) 

Timer  and  Counter  processing 

(ID 

Message  Processing 

To  support  these  FIF  functions,  the  following 
standardized  procedure  are  prepared. 

(1) 

Operator's  console  functions 

(2) 

Task  control  functions 

(3) 

PROCOS  language  processor 

(4) 

System  generation  and  Data  base  preparation 

-11- 


PROCOS  exhibits  1 1 le  next  capabilities  of  applications. 

(1)  Process  data  gathering  and  reporting 

(2)  Calculation  of  indirect  measurement  value  and 
process  performance 

(3)  Monitoring  and  alarming  of  abnormal  process 
status 

(4)  Supervisory  and  set  point  control 

(5)  Direct  digital  control 

(6)  Sequence  control 

(7)  Man  machine  communication  by  process  operator's 
console  and  message  typewriter 

(8)  On-line  system  modification  and  easy  system 
change 

(9)  System  protection  and  security 

2.2  Requirements  ol  computer  resource 

PROCOS  is  considered  to  utilize  the  following  computer 
capabilities 

(1 ) Host.  Machine 

(1.1)  To  perform  simulation  of  16  bits  machine 

(1.  2)  7’o  have  more  than  32K  bytes  main  memory 

(1  . 3)  To  have  more  than  51 2I<  bytes  auxiliary 
random  access  memory 

(1.  4)  To  use  FORTRAN  compiler 

(1.5)  To  make  easily  data  base  by  using  index 
sequential  file  processing 


(2)  Target  Machine 

(2.1)  lfj  bits  machine 

(2.2)  More  than  ItiK  bytes  main  memory 

(2.  3)  CRT  operator's  console  or  console  input/ 
output  typewriter 

(2.4)  Required  random  access  memory  to  store 
PROCOS  data  base 

(2.  5)  Required  main  memory  to  store  data  base 
and  program  of  DOC 

2.  3 Basic  program  configuration 

The  programs  of  PROCOS  are  consisted,  by  many  kinds 
of  functional  programs  that  are  as  follows. 

(1)  Functional  program  scheduling  program 

(1.  1)  Process  variable  processing  scheduling 

(1.2)  Process  monitoring  scheduling 

(1.  3)  Calculate  scheduling  (PROCOS  language 
executive  scheduling) 

(1.4)  Message  and  Reporting  scheduling 

(2)  DDC  scheduling  program 

(3)  Process  variable  handling  program 

(3.1)  Input  handling 

(3.2)  Conversion  handling 
(3.  3)  Output  handling 
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(3.  4)  Variable  and  status  editing  fl 

(3.  5)  Process  monitoring  1 

( 3 . ti ) DDC  function  j 

(4)  PKOCOS  language  interpreter 

(5)  Message/Report  interpretei’ 

(6)  Operator's  console  function  program 

(6.  1)  Operator's  console  executive 

(6.2)  Operator's  console  service  function 

(7)  Data  base  generation  and  maintenance  program 

(8)  System  initialization  program 

(9)  System  diagonostics  program 

These  programs  must  be  developed  from  the  following 
view  points. 

(1)  Restriction  >f  generalization  (Flexibility  and 
Applicabil  ity) 

(2)  Compact  design 

(3)  High  response  characteristics 

(4)  Definition  of  hardware  address  and  name 

(5)  Inter- linkage  with  operating  system  (OS) 

(6)  Inter-linkage  with  procedural  language 

(7)  Program  development  support 

(8)  Program  simulation  aids 


(9)  Machine  independence 


To  make  these  functional  programs  of  PROCOS  by 
using  FORTRAN,  there  are  following  poim.-,  to  be 
settle 


(1)  Target  code  efficiency 

(2)  Data  base  fai  iliiiet- 

(3)  Bit  string  manipulation 

(4)  Storage  allocation 

(5)  Task  control 

(6)  Program  control 

(7)  Parallel  I/O  processing 

(8)  Adoptability 


L 


\ 
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3.  FIF  Design 

3. 1 Purpose 

The  purpose  oJ'  the  fill  in  the  form  ( FIF ) is  easy 
documentations  and  one  writing  program  preparation 
works. 

FIF  must  be  designed  to  satisfy  the  following  require- 
ments . 

(1)  Easy  use  for  control  engineer  or  system  designer, 
but  non-computer  engineer. 

(2)  Select  descriptive  items  that  are  application 
oriented. 

(3)  Easy  modification  by  using  operator's  console. 

(4)  Good  documentation. 

(5)  Easy  writing  user’s  function  by  using  PROCOS 
language. 

3.  2 Use  of  FIF  forms 

FIF  forms  are  writen  by  user  or  system  designer, 
prepared  as  card  media  or  paper  tape  media  and 
stored  in  the  defined  area  of  data  base. 

The  format  of  FIF  are  shown  in  the  next  page. 

The  items  which  are  required  for  internal  processing 
in  computer  are  not  specified  in  the  FIF  formats. 

3.  3 Naming  of  Variable 

Variable  name  is  consisted  by  the  six  characters  and 
auxiliary  code  ( two  characters)  that  the  first  character 
is  alphabetic. 
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II',  variable  name  of  digital  or  logical  variable  is  not. 
given  for  single  bb  ’Ins  nano-  are  given  automati- 
cally as  PI  XXXX  ior  digital  input  and  lit)  XXXX  for 
digital  output. 

3.  4 Use  of  calculate  processing 

The  form  sheets  of  Calculate  are  writer  by  using 
PROCOS  language.  These  described  sheet's  contents 
are  condensed  and  translated  in  pseudo-interpretive 
code  for  easy  execution. 

3.  5 Use  of  Message  and  Report  writing 

The  form  sheets  of  Message  and  Report  writing  are 
wrilen  by  using  following  rule 

(a)  Designation  of  line  position 

P : Mew  page 
W : Write  in  W-th  row. 

SW  : Skip  the  W- pieces  of  rows 
SO  : Print  in  the  following  print  position 
Blank  : Change  the  row  and  print 

(Where  W is  integer  number.  ) 

(b)  Designation  of  character  position 

W : Print  after  W-pieces  of  characters 
Blank:  Print  in  the  following  position 

(c)  Message 

° n X - Blanks  (n-pieces) 

° ni  n2-  ■ • rtn  ; character  strings 
° % p (di  d2.  • ■ ■ dtl) ; Description  ol  process 

where  p:  Process  variable  name 

df:  Process  variable  elements 


NAME  w : Process  variable  name 
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Fw.  d,  Evv  d,  Dw.d,  I\v:  Value 

UNIT  w ; Engineering  unit 

STATUS  S\\  ; Status 

(n)  Fw.d  ; Valve  of  Auxiliary 
Code  (n) 

nX;  Blanks  (n  - pieces) 

° DATE  ; Present  date 

° TIME  ; TIME 

0 MESEND  , End  of  message 


» 


30  33  »-  Column  position  (In  curd) 

HZI  CZZZZZ]: 

I I 

1 i 1 L..l  J»  Lx.,  j ......  1 : 


Distinction  of  data  (In  paper  ’ape) 


Distinction  of  line  (In  paper  tape) 


Description 

— *■  Identification  no.  of  line 
Identification  of  FIF  form 


Nortation  in  FIF  form 


2 


! Vorc  . YnriaMo  7nmi4  Processing' 


36  39  40  41 


EE 


44  45 

EH  □. 


46  51 


52  54  55 


foD  1 . H , □ ; 

56  58 

eh 


60  61  65 


EH  □ = 


6?  68 

EH  □ .□  : 


Variable  Name 

Description 

l pper  Value  of  St  ale 

Lower  Value  ol  Scale 

I'iu: . I nit.  Scale  factor 

PDC/FEEDE  VC K.  .Larct 

! pe  of  rermir.al.  Croup  of  ' <»ld 
I unction 

Terminal  Address 
Scan  Interval.  Time  unit 

Upper/Lower  Limit  for  Si^ral 
Reject 

Alarm/ Action  Name 

Variable  Name 
Conversion  Eq.  No. 

• A 

B Conversion  Parameter 
C 

D 

Variable  Name  (Temp.  ) 

(Press. ) 
(MW/SI'GR) 

Filter  Constant 

Statistical  Data  Processim. 
Code  and  Time  B:i-e 


I ! 

S 


f 
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Proce  a-  \ ariable  Monitoring 


EH  1 ....  . 

• Variable  Name 

eu  fa  = 

Monitoring  Group 

10  12  13 

O 

w 

□ 

Interval.  Time  Ha.-e 

14  IS 

20 

eh  i . . . 

, : Filter  I'vne  and  Constant 

EE  fa 

Dead  baud 

23  24 

29 

EH  n-r, . . . 

, | ; > pper  Limit  Value 

30  31 

3 6 

eh  ri-  r . . . 

, | : Lower  Limit  Value 

37  38 

43 

EE  l . . . 

. 1 ■ Alarm/ Action  Name 

4 4 45 

50 

EE  D 

i 1 : High  High  Limit  Value 

31  52 

57 

EE  D L^.  i 

, J;  Low  Low  Limit  Value 

58  59 

60 

mi  c nz 

, I l Alarm /Action  Name 

EH 

7T1: 

Variable  Name 

8 9 

14 

EE 

D HZ 

■ ■ i i 1 • 

Ila  e of  Change  Limit 

1 5 16 

21 

EE 

d cm 

. . . i I* 

Alarm/ Action  Name 

22  23 

28 

EE 

D Lu_ 

29 

, . . . 1: 
34 

Deviation  Change  Limit 

|0.5  | 

1 . . . 

• 1 * 

Set  Point  Variable  Name 

35  36 

41 

EE 

P>  EE 

77771: 

Alarm/Action  Name 

42  44 

foT 

! 1 ’ 

Alarm  Indicator 

1 


J 


. ,*  f + 
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' 


i 


i 

i 

i 


4 


I 


1 

I 

( 

. 

% 

I 

i 


Process 


I 


Variable  Output  Processing 


E 


2 T 


0,1  1 . . . 

. 8 

HZI: 

23 

ra  rrr^ 

1 L l » • • 

lAU  L , ■ 

S3  I3,  . ■ 

36  39  40  «? 

E3 


43  44  45 

lAH  Q • Q • □ ; 


.46  51 

ro  i,  : "v.  i 

E3  tZP 

_53 

59 

L 0,  91  | 1 

60 

65 

1,0  1 

66 

Tl 

LLil  L.C..U.,  t , 

Variable  Name 

Description 

Upper  Value  of  Range 

Lower  Value  of  Range 

ENG.  I 'nit,  Scale  Factor 

Hardware  Type,  Outpu'  Type 
Device  Type 

Terminal  Address 
Conversion  Eq.  No. 

A 

B Conversion  Parameter 
C 


SID  I . . . 

33  = 

Variable  Name 

E)  £].  tl 

. 7T  !4|: 

Feedback  Variable  Name- 

El  t5,  ■ . , 

20 

ZD  : 

Feedback  Limit  Value 

Lii  r. . . 

26 

ZD 

Output  Limit  Value 

27  28 

33 

IoaICMZI 

■ , , . n 

Alarm/Action  Name 

1 


Logical  Variable  Processing 


CO 

2 

CO 

8 

J i— . 

7 

o- 

23 

Variable  Name 

roi 

ro 

. i . 

1 1 l > 

• 11!  1 • 1 1 

Description 

24 

25 

CO 

□ . 

CO 

Signal  Type,  Contact  J'.pe 

26 

27 

32 

33  35 

CO 

too 

zzn- 

Editing  Function 

37 

38 

43 

44  46 

CO 

... 

. . . 1 

.00(00 

Terminal  Addrei- 

48 

49 

54 

55  57 

ro 

, , , 1 

• LOO  l: 

° Bit  Pdsitioi: 

54 

60 

65 

66  68 

LO 

□ . 

oo 

» 

-GO  (GO 

° Bit  Length 

i 

2 

7 

. 

roi 

. 1 1 i ! 

8 

CO  •• 

23 

roi 

1 . . . 

Cm! 

24  25 

COCO 

ron 

26  27 

32  33  35 

no  : 

, . . .1,0  1.01; 

3 7 38 

43  44  46 

n-co 

48  49 

~r~n.r~i.r~r 

54  55  57 

tx> 

o' 

LJ.  0_j 

59  60 

l > i ! * i — i ! * 1 i 1 . 

56  66  68 

33  g>lo: . . pi-coom 


ion 

2 

— 1 1 l — ^ 

8 

7_ 

— 1 L * 

23 

on 

r~ 

• • • 

' 71 

no 

2S  n 

S3  33  35 

Ca  4] 

□.co 

J.GJ.CGI; 

□0 

3 7 38 

□ .GO 

43  44  \ 6 

_i_u_J.C01.C03 : 

COJ 

48  49 

□00: 

54  55  57 

_i 1 J . GJ  ■ COD  : 

on 

59  <0 

□•GO 

65  66  68 

GGZ)’  CONGO 

Status  Change  Detecting 


Variable  Name 


Trigger  Condition,  Task  Name 


14 


Digital  Output  Processing 


Variable  Name 

Description 
Output.  Logical  Name 

FB  Check  Logical  Name 
I )elay  Time  for  ( I :eck 
Alarm/ Action  N 2 ' • a- 


45 


DDO  Processing  < 1 ) 


l 

2 

7 

[I  SI] 

■ - i » » » .. 

8 10  11 

□ 

• 

Process  Variable  Name 

[VI 

■ . 1 ’ LJ 

12  13  14 

• 

14 

Interval,  Time  Base 

1 0.3  1 

g 

□ 

□ 

...  1 

Output  Type,  Type  of  Value,  Output  Addres 

20 

25 

[Ml 

: ‘ 

KP  (Gain) 

26 

31 

ES 

KJ  (Reset) 

32 

37 

[Mi  rsssrs 

: 

KD  (Rate) 

38 

43 

0.7 

Deadband  to  Output 

[Ml 

44  45 

46 

51 

PV  Conpensation,  Squared  Deviation 

[0.91 

1 

• 

T1 

52 

57 

Sol 

i . . . . 

= 

T„ 

Sjj 

58 

□ : 

59 

64 

2 

Mode  (Direct,  Reverse) 

[Ml 

1 , . . , 

: 

A 

65 

70 

Output  Conversion  Parameter 

QS 

1 ■ ■ ‘ 

□ 5 

B 

[k|  CoS 

Alarm  Option 

2 1 

1 1 

Process  Variable  Name 

8 

13 

POl 

1 . . . . 

Set  Point  Upper  Limit  Value 

14 

19 

f0,  3| 

1 . . . . 

Lower  Limit  Value 

20  21 

26 

foTSl 

n ,r~r 

. * 

Alarm/Action  Name 

27 

32 

[Ml 

l , . . . 

Is  . 

Deviation  Limit  Value 

33  34 

39 

[ o.  el 

n ,r~~ 

; 

Alarm/Action  Name 

40 

45 

[Ml 

i . . , ; 

1 : 

Maximum  Change  Rate 

46 

SI 

1 0.  8| 

i . r 

1 J 

Maximum  Rate  of  Change 

52  53 

58 

fOl 

□ rrz 

. • 

Alarm/Action  Name 

«*•  * 


•4XK  * 


DDL  Processing  '2) 


Process,  Variable  Name 


! O' 

9 14 


J » i 1 1 

l_5 20_ 

1 i t i — j — i — 

l 26 


Ratio  Control 

Input  Variable  Name 

Ratio 

Cia  , 

bet  Point  High/ Low  Selecting  Contro 


. a r table  Name 


ariable  Name 


40 

□ : 

Cascade  Control 

41 

46 

1 , , , 

. . 1; 

Variable  Name 

47 

Output  High/Low  Selecting  Control 

43 

53 

Variable  Name 

r,  , , 

; 

54 

i . 

« j — v * 

Special  Control  Function  Name 

Timer  and  Counter  Processing 


7 


Timer  or  Counter  Name 

Description 

Type 

Count  Address 
Drived  Task  Name 


sing 
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4.  Data  base  design 

■ * 

4.  1 General 

The  data  base  of  l’ROCOS  system  is  designed  for  easy 
modification  and  build  up.  module  structure  and 
expandability,  and  easy  documentation. 

The  access  of  data  base  is  done  by  using  process  variable 
name  which  is  given  at  FIF  forrnsheet  by  user. 

The  data  base  at  execution  phase  is  consisted  as  follows 
and  its  details  are  shown  the  table. 

I i 

(1)  File  for  Processing  procedure 

(2)  File  for  Variable  value 

(3)  File  for  Status  and  condition 

I 

(4)  File  for  Address  pointer 

(5)  File  for  Executive  scheduling 

For  system  generation  and  preparation,  Source  Input  data 
by  using  FIF  is  filed  in  Source  Data  Base. 

4. 2 Data  base  access 

■ 4 

Data  base  in  PFOCOS  is  refered  by  using  the  following 
procedures . 

I *» 

(1)  Variable  name 

Exp.  FRC  101  (PV) 

FRC  101  (VP) 

(2)  Access  as  vector  data  or  data  base  block. 

iExp.  GET  (FRC  101) 

PUT  (FRC  101) 
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(3)  Access  from  User's  FORTRAN  program 

Kxp  call  c.irr 
CALL  PUT 

4.  3 Data  base  protection 

Data  base  and  its  attribute  is  design  to  protect  destruction 
4.  4 File  structure 

Data  base  is  design  by  using  the  fixed  records  file  and 
variable  records  file  for  each  usages. 


WK  * 


A'- aloe  in  "Lit 
torinari  .ed 
. -ilu-  Pile 


honi  tonnr 
Pointer  Pile 


M<  mi  t.orin, 


' 3tat is ♦ ical 
| Data  File 


; A-  .* 1 1 o p lean 

I 

|‘.aalo-'  Pear 

f 

Pro  rani 

I 

j Pi  1 e 

n 

il  i o-  r : 

i 

fj" 

Mi::  itori 

' 

^ 

i Monitoring 

]= 

Pro  ram 



r 

1 ni.  , | 

basic  Relation  bet.  eer-  Data  nse  arid  Pro.- ram  (l 


5.  PUOCOS  language  design 

5. 1 Purpose 

PROCOS  language  is  utilized  to  make  user's  functional 
program  This  language  is  designed  as  reduction  of 
FORTRAN  statements. 

This  language  lias  the  functions  of  arithemetic  procedure, 
hits  and  logical  manipulation,  data  base  input  and  output 
handling,  simple  message  handling. 

The  main  applications  area  are  as  follows. 

(a)  User's  special  logics. 

(b)  Special  compensation  and  conversion 

(c)  Advanced  control  logics 

(d)  Abnormal  function  procedure 

5. 2 Language  processing 

PROCOS  Language  is  writen  in  FIF  form  sheets.  The 
described  statements  in  FIF  are  converted  in  intermediate 
language  (Pseudo-code)  and  stored  in  data  base  for 
execution . 

In  execution  phase,  this  pseudo-code  is  interpreted  and 
executed. 


5.  3 Statements  of  PROCOS  language 
(1)  Constant/ Variable 


(a) 

Real 

FORTRAN  TYPE 

(2 

Words) 

(b) 

Integer 

f 1 

(1 

Words) 

(c) 

Binary 

B "101" 

(1 

Words) 

! 
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(2)  Variable  Name 

Be  based  on  FORTRAN 

(3)  Arithemetic  operators 

Be  based  on  FORTRAN 

(+  *,  /,  **.  (.)  ) 

(4)  Relational  operators 

Be  based  on  FORTRAN 

(,EQ.,  . LT.  , , LE,  , . GE.,  . GT.  , . NE.) 

(5)  Logical  operators 

Logical  operations  (OR,  AND,  EOR,  NOT) 
are  operated  as  16  Bits  base. 

(6)  Operation 

Be  based  on  FORTRAN 
(By  using  = (equals) 

(7)  Test  and  Branch 

Using  Logical  IF-  of  FORTRAN 

(8)  Branch 

Unconditional  GO  TO 
Computed  GO  TO 

(9)  End  of  Execution  (Return  to  OS) 

STOP 

(10)  End  of  Statements 
END 
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(11)  Keep  the  area  of  PROCOS  for  future  extension 

SPACE  (n) 

(12)  Subroutine  call 

Be  based  on  FORTRAN'S  CALL 

(13)  functional  and  Subroutine  subrograrn 

Not  defined 

(14)  Basic  external  functions 

EXP(x),  ALOG(x), 

SQRT(x),  ABS(x) 

N.B.  It  is  possible  to  add  a user's 
subroutines. 

(15)  Comments 

Be  based  on  FORTRAN 

(16)  Statement  number 

Be  based  on  FORTRAN 

(17)  Message  print 

PRINT  Message  no. 

(18)  Arrays  (or  Dimention) 

Not  defined 

(19)  Status  call 

Using  Macro  call 

(20)  Program  drive 


START  (i,  j.  k.  m) 


Interpretive  Code 


Inter  Data  Base  Address 


Absolute  Address 


Relational! 


Equation 


unconditional  GO  TO 


CALL 


oU  O' 


CALL 


Branch 


'outine 


MI3C 


STOP 


Classification  of 


1 Word  Constant 

2 Words  Constant 

Variable 

1 Word  /ariable 

2 Words  Variable 

1 
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6.  Task  control  and  program  design 

For  executive  control  of  PROCOS,  the  special  designed 
task  control  functions  are  prepared. 

In  general,  there  are  the  task  control  tables  to  register 
status  and  conditions. 

Priority  interrupt  handling  is  designed  according  operating 
system  (OS)  and  hardware  characteristics. 

These  task  control  tables  have  the  capabilites  of  cyclic 
processing  and  demand  (or  request)  processing. 

In  the  following,  there  are  shown  the  task  control  relations 
and  the  basic  program  relations. 


PROCOS 


PROCOS 


PROCOS  i 


Operation  in  .<•  0KS3  (l) 
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7.  Operator's  console  function  design 

7 . 1 General 

The  operator's  console  of  1MIOCOS  is  utilized  by  using 
CRT  console  as  character  display  and  data  entry  system. 

7.2  Functions  of  Operator's  console 

(1)  Process  data  display  (by  cyclic  display) 

(1.1)  One  point  digital  display 

(1.2)  Multi  point  digital  display 
(1.  3)  Multi  point  bar  display 
(1.  4)  Multi  point  trend  display 

(2)  Param’eter  display 

(2.  1)  Data  base  parameter  display 

(2.2)  Control  parameter  display 

(3)  Data  base  page  display 

(4)  Process  data  setup 

(4.  1)  One  point  data  set  up 
(4.  2)  Multipoint  data  set  up 

(5)  Data  base  parameter  set  up 

(6)  Data  base  condition  set  up 

(7)  Data  base  page  set  up 

(8)  Request  functions 
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(8.  1 ) Tune  display 
(B.  2)  Display  request 
(B.  3)  Assign  group 
(B.  4)  Report  request 
(8.5)  Alarm  summary  print 
(8.  6)  I/O  signal  test 
(8.7)  Cancel 
(9)  Alarm  display 

(9.  1)  Computer  error 
(9.  2)  Computer  running  status 
(9.  3)  Process  monitoring  alarm 
(9.  4)  Operator's  console  manipulation  error 
(10)  Control  loop  manipulation 
(10.  1)  DDC  loop  switching 
(10.  2)  Analog  output  loop  switching 
(10.  3)  Manual  output  manipulation 
(10.4)  Loop  status  display 


1 


-59- 


8.  System  generation 

For  flexibility  and  expandability,  the  following  functions  of 
system  generation  are  pr>  pared. 

(1)  Data  base  generation 

(2)  Program  generation 

(3)  Executive  program  module  generation 

(4)  Documentation 

Basic  functions  of  host  computer  are  as  follows. 

(1)  File  creation 

(2)  File  condensation 

(3)  File  modification  (or  up  to  date) 

; 

(4)  Documentation 

(5)  Program  generation 

Basic  functions  of  target  computer  are  as  follows. 

(1)  Program  load 

(2)  File  load 

I 

; (3)  File  change  and  delete 

(4)  Memory  allocation 

(5)  File  dump 


I 


System  Generation 
Program  Read  & Exec 


[Host  Computer 
[Job  control  card 


FIF  Deck 


Translate  and  Conv 


FIF  Conversion 


Converted  6e 
Condensed  Data 


System  Generation 


lSystem  Generation 

Program  Text 

i 

Generation  Parameter 

/ f 

Basic  Gen  era  tin  | 

Read  In 

Parameters 

Diagonos  tic 
List 


Executive  Data  Base 
Output 


Executable  Data 
Base  Deck 


Executive  Data  Base 
Text  Punch 


Data  Base 
Structure  Table 


FORTRAN  Compiler 
ASSEMBLER 


User's  Program 
Card  Deck 


System  Generation 


1 

Pre  Processor 

• i 

Executable  Data 
Base  Records 

x J 

1 

- 
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SECTION  II 


OUTLINE  OF  AN  EXPERIMENTAL  PL/ I 
COMPILER  IMPLEMENTATION  FOR  A 
MEDIUM  SCALE  INDUSTRIAL  COMPUTER 

i 

I 


1 I 

i 

4 

' 

There  has  always  been  considerable  interest  in  both 
the  Japanese  and  American  branches  of  the  Workshop  in  the 
possible  use  of  PL/I  as  the  basis  for  the  LTPL.  The 
attached  document  from  the  Fourth  Minutes  of  the  Purdue 

i 

Workshop  on  Standardization  of  Industrial  Computer  Lan- 

!guages  (pp.  224-232)  describes  one  such  implementation 

carried  out  in  Japan. 


i 

t 

l 


OUTLINE  OF  AN  EXPERIMENTAL  PL/ I COMPILER  IMPLEMENTATION  FOR 
A MEDIUM  SCALE  INDUSTRIAL  COMPUTER 

M.  SUDO 


1-  INTRODUCTION 

It  is  a fact  that  PL/I  is  a promising  language  and  is  expected  to 
fill  the  demands  which  have  not  been  gained  with  existing  procedural 
languages.  On  the  other  hand,  it  is  pointed  out  that  the  versatile  features 
of  PL/l  would  require  a number  of  new  schemes  in  practical  implementation 
of  compilers. 

We  had  an  experience  to  implement  a PL/I  subset  compiler  for  a medium 
scale  computer  prior  to  designing  the  compiler  for  another  larger  machine. 
The  computer  used  in  this  experiment  is  a medium  scale  industrial  computer 
with  16  KW  core  memory  and  with  some  rotating  type  bulk  memory  devices, 
which  happens  to  be  the  same  as  the  basic  assumptions  of  the  workshop 
report  refers.  The  main  objective  of  our  experimental  implementation  was 
not  to  develop  a practical  compiler  for  that  machine  but  to  investigate 
the  appropriate  compiling  techniques  for  those  functions  which  PL/l  newly 
adopted . 

Although  our  compiler,  therefore,  does  not  suggest  directly  to  the 
design  of  procedural  languages  for  industrial  use,  there  may  be  some 
implicative  suggestions  to  the  definition  of  PL/l  like  procedural  languages 
for  medium  scale  computers,  especially  in  case  of  defining  the  language 
through  selecting  a practical  subset  from  the  full  PL./l  specification. 
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| i 

2.  Language  Specification 


2.1  P TOC, RAM  ELEMENTS 


PL/ 1 

Experimental  Subset 

~ 2.1.1  Basic  Language  Structure 

a.  Language  Character  Sets 

60-character  Set 

48-character  Set 

48-character  Set 

* b.  Delimiters 

Operators 

Pax entheses 

Separators 

c.  Data  Character  Set 

d.  Collating  Seauence 

e.  Identifiers 

( 

> the  maximum  length  of 

the  maximum  length  of  identifiers 

identifiers  is  implementation 

is  31 

defined 

f.  Keywords 

Keywords  are  not  reserved  words 

Keywords  are  not  reserved  words 

1 

except  the  operators 

4 

(AND,  OR,  NOT,  GT,  NG,  GE,  NE, 

LE,  LT,  NL) 

g.  Use  of  Blanks  and  Comments 

* 

Same  as  PL/l 

2.1.2  Basic  Program  Structure 

Same  as  PL/l 

i 

a.  Simple  Statements 

b.  Compound  Statements 

* c . Grouos 

i d.  Blocks 

( 

| Procedure  Blocks 

I Begin  BIocks 

e.  Program 


< 

t 
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PL/I 

1 

| Experimental  Subset 

' ""  i 

2.2  DATA  ELEMENTS 

I 

i 

2.2.1  Data  Organization 

1 

a.  Scalar  Data 

b.  Data  Aggregates 

Arrays 

Structures 

i 

Arrays  of  Structures 

j Structures  are  prohibited. 

Upper-  and  lower  bound  are  defined 
with  constants. 

1 

2.2.2  Naming 

a.  Simple  Name 

1 

Simple  Name 

b.  Subscripted  Name 

l 

Cross  section  of  array 

Subscripted  Name 

j 

i 

c.  Qualified  Name 

| 

1 

d.  Subscripted  Qualified  Name 

I 

2.2. 3 Data  Types 

1 

1 

i 

i 

a.  Problem  Data 

arithmetic  data  ] 

real/complex 
fixed/float 
binary/decimal 

| 

! complex  is  prohibited 

i 

1 

string  data 
bit/character 

fixed  length/varying  length 

Length  of  string  is  defined  with 
constants. 

b.  Program-Control  Data 
label  data 

label  data 

entry  data 
task  data 
event  data 
locator  data 
area  data 
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PL/I 


2.3  DATA  MANIPULATION 

2.3. 1 Scalar  Expressions 

2.3.2  Aggregate  Expressions 


Experimental  Subset 


Same  as  PL/l 
Prohibited 


2.4  DATA  DESCRIPTION 

2.4.1  Declaration 

2.4.2  Attributes 

a.  Problem  Data  Attributes 
REAL/COMPLEX 
BEN ARY/DECIMAL 
FIXED/ FLOAT 
Precision 
3IT/CHAKACTER 
Length 
VAPYING 
PICTURE 


Same  as  PL/l 


BINARY/DECIMAL 

FIXED/FLOAT 

Precision 

| 

| BIT/CHARACTER 
Length 
VARYING 


b.  Control  Data  Attributes 

label  label 

ENTRY 

TASK 

EVENT 

POINTER 

OFFSET 

AREA 

c.  Entry  Attributes 

ENTRY  ENTRY 

VARIABLE 

RETURNS  RETURNS 

REDUC 1 BLE/I RRUDU  C 1 3LE 

GENERIC  i 

BUILTIN 

OPTIONS 


r 
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BACKWARDS 

ENVIRONMENT 

KEYED 

I 

EXCLUSIVE 

e.  Scope  Attributes 

INTERNAL/EXTERNAL  INTERNAL/EXTERNAL 

f.  Storage  Class  Attributes 

STATIC/AUTOMATIC/CONTROLLED/BASED  I STATIC/AUTOMATIC 

g.  Others 

ALIGNED/UNALIGNED 

CONNECTED 

DEFINED 

INITIAL 

LIKE 

POSITION 

Parameter  Parameter 

i 

Dimension  ! Dimension 

■ 

2.5  INVOCATION  OF  PROCEDURES 

2.5.1  Procedure  References  [ Same  as  PL/l 

2.5.2  Argument  Passing 

a.  Call  by  Name 

b.  Argument 
Scalar  argument 

Aggregate  argument  is  prohibited. 

Aggregate  argument 


t 

i 


PL/I 

2.5*5  Generic  Names 

2.5.4  Built-in  Functions 
2.^.5  RECURSIVE  Option 

2.6  Dynamic  Program  Structure 

2.6.1  Block  Control 

2.6.2  Storage  Control 

a.  Static  storage  class 

b.  Automatic  storage  class 

c.  Controlled  storage  class 

d.  Based  storage  class 

2.6.5  Multi-Tasking 
2.6.4  Interrupt  Operations 

2.7  Input/Output 
2.7-1  Opening  and  Closing  Files 

2.7.2  Data  Stream  Transmission 

2.7.3  Record  Transmission 

2.8  Statement, 

a.  Assignment  Statement 

b.  Control  Statements 

30  TO,  IF,  DO,  CALL,  RETURN, 
WAIT,  STOP,  EXIT,  DELAY,  Null 

c.  Data  Declaration  Statement 

DECLARE,  DEFAULT 

d.  Error  Control  and  Debug  Statement. 


1 

Experimental  Subset 

J Prohibited 
| 

Prohibited 

I 

j 

i 

Same  as  PL/I 

Static  storage  class 
Automatic  storage  class 

i 

| 

Prohibited 

■ Prohibited 

| 

I/O  functions  are  implemented  by 
subroutine  reference. 


Assignment  Statement 

I 

■ 30  TO,  IF,  DO,  CALL,  Rt.T'jKN,  Null 
j DECLARE 


ON,  SIGNAL,  REVERT 
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Experimental  Subset 

e.  Input/Output  Statements 

Implemented  by  subroutine  reference. 

i 

open,  CLOSE,  DELETE,  UNLOCK, 

GET,  PUT,  FORMAT,  READ, 

WRITE,  REWRITE,  LOCATE,  DISPLAY  1 

f.  Program  Structure  Statements 

i 

PROCEDURE,  BEGIN,  END,  DO,  PROCEDURE,  BEGIN,  END,  DO,  ENTRY 

ENTRY  j 

g.  Storage  Allocation  Statements 

ALLOCATE,  FREE 

h.  The  Others 

FETCH,  RELEASE,  INCORPORATE 


2.9  Compile-time  Facilities 


Not  implemented 
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Compiler  Organization 
S.1  System  Flow 


Source 

Program 


Phase  1 

J — 

o Lexical  Analysis 
o Syntax  Analysis 


Sourc  e 
List 


V 


Phase  2 




^ 

Symbol 

j Dump 

j List 

; List 

[ 

l ^ — 

I Object  Codes 

I 

i Dump  List 


o Processing  Dec larations 
o Symbol  List 
o Dump 


Phase  5 

o Semantics  Analysis 
o Code  Generation 

n 

I 

I • 

P S 


L 


• 

Intermediate 
, I Information 


Assembler 
Source 
Program 


, Assembly  i 
List 


I 


- - J 


I 

L. 


Assembler 


• / 

y 


FftSt SPINS  PA3ti'^fcAI0C-N0T  FILMED 


SECTION  III 


STANDARD  SOFTWARE  FOR  CAMAC- 


COMPUTER  SYSTEMS 


The  developers  of  the  CAMAC  standard  hardware  systems 
for  nuclear  instrumentation  (see  Section  I,  Part  III  of 
this  Summary)  have  also  been  active  in  the  development  of 
macro-assembly  codes  for  use  with  this  equipment . This 
Section  presents  two  documents  describing  this  "language." 

The  first  document  .from  the  Minutes  of  the  Eighth 
Meeting  of  the  Purdue  Workshop  on  Standardization  of  Indus- 
trial Computer  Languages  (Insert  VIII-2,  pp . 89-99)  and  the 
second  from  the  Minutes  of  the  Ninth  Meeting  (Appendix  III, 
pp.  179-184)  present  the  United  States  and  European  recom- 
mendations concerning  this. 


t 

i 


Specifications  for  CAMAC  Subroutines 

i 


4 


bv 

Richard  F.  Thomas,  Jr. 
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This  report  lias  been  prepared  under  the  guidance  and 
sponsorship  ot  the  CAMAC  >ottware  Working  Group  of  the  U.  S. 
AF.C  NIM  Committee.  it  contains  descriptions  of  six  FORTR/*.’- 
oompatible  subroutine-.  recommended  for  use  with  CAMAC  -ystems. 
These  subroutines  permit  the  most  general  operations  on  a 
CAMAC  system  to  be  specified  in  a high-level  programming 
language.  Two  of  the  subroutines  implement  the  fundamental 
CAMAC  functions;  three  of  them  implement  the  three  :•<•£  of  the 

i . ■ ■ 25875;  t ■ ■ i 

vides  a flexible  alternative  for  CAMAC  addr.-ssing. 


t 

< 


The  N IM- CAMAC  Software  Working  Group  has  agreed 
th.it  the  specification  of  a standard  sec  of  subrou- 
tines for  performing  CAMAC  operations  would  be  of 
use  in  facilitating  communication,  permitting  inter- 
change- of  programs  and  saving  of  design  effort  in 
the  implementation  of  CAMAC  systems.  The  subroutines 
should  be  applicable  to  as  many  languages  as  possible, 
but  mast  be  compatible  with  FORTRAN,  which  is  the 
most  widely  used  high-level  language  in  the  11.  S. 
it  this  time.  This  report  describes  six  subroutines 
which  the  Working  Group  recommends  for  standard 
usage.  Other  subroutines  are  under  active  considera- 
tion, but  it  is  f It  that  the  best  interests  of  the 
CAMAC  user  community  are  served  by  rapid  publication 
of  tuo  specifications  which  have  been  agreed  upon  to 
date . 

The  approach  which  has  been  followed  in  the 
following  specifications  is  chat  a single  subroutine, 
"CMCHSC,rt  capable  of  performing  a very  general  CAMAC 
operation,  is  specified  in  terms  of  its  inputs  and 
outputs.  Then  other,  more  specialized,  subroutines 
ir.  defined  as  FORTRAN  subroutines  which  make  use  of 
r h fundamental  subroutine,  "CMCBSC."  It  should  be 
especially  noted  that  although  ail  subroutines  er:  *pt 
’'CMCBSC'*  ire  defined  as  FORTRAN  subroutines,  nn 
ii. dividual  installation  will  quite  likely  find  it 
• •Ivantageous  to  implement  many  of  them  in  assembly 
language,  or  perhaps  in  other  special  vays,  in 


order  to  take  advantage  of  loca  hardwan  and  sp-  . 
up  their  execution.  tbes<  • • : • 

subroutine  will  serve  only  as  a definition  Hovt-. 
any  installation  which  can  provide  a t : : •-* 

"CMCBSC"  and  i FORTRAN  compiler  will  • 

available  :»  library  of  CAMAC  procc-d 

The  following  genera!  remarks  at  , t 
scriptions  of  all  the  subroutines  whi-!.  * -.  Ir. 

specifying  subr  "r  im  arguments  r.-in-s  r, 

which  may  be  or  mu-  r be  arrays  end  with  *.  • 1 - 1 1 • r 

"A,"  and  all  arguments  ire  Integex  . . 

FORTRAN  sense.  All  subroutines,  funt 
Common  names,  i.*.,  1 global  r.r-  ► wit 

• 1 . - ‘ : 

extension  of  th»  standard  subroutine  . the  max- 

imum extent  practical  in  tin  spec  : f i cat  i<  ru  argum*  * 
names  and  meanings  are  Identical  fr  • one  *•  <:br . v:  ? i uc 
to  another.  Certain  arguments  (esp,  » 1 ! v ratt 
nundier . t » pea  t count , 

are  explained  in  detail  in  th-  dcs*  rlption  * if  : 

tine  **GMGBSCm  and  mly  rial  • In  tl  lei  aitiont 

subseouv.-*  subrout  i .os.  However,  the  lull  Cofi’w: 
is  intended  tu  ipply  in  every  .as. 

It  is  necessary  for  many  of  the  subr  utir.ts  t 
have  -access  to  the  values  of  certain  const  int>  - ; 
describe  the  system,  in  particular  t.-  ; 

of  the  computer,  the  number  oi  nodul*  p , 

the  number  of  era?  per  branch*  In  r ’ i* 


< 


...  »- 


* 


*•'*»*- 


\ 


Mi 
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T 


subroutines  tun  bv  written  in  a general  way  and  be 
reasonably  Independent  ot  the  actual  values  of  these 
quantities,  a named  common  which  contains  the  values 
tor  the  system  Is  defined,  a sample  "BLOCK  OAT A" 
subroutine  is  given  in  Fig.  1 for  lt>-b.'  umputer 
with  normal  values  lor  the  quantities. 


the  sign  Indicates  computer-length  w .1 

positive  and  CAMAC- length  u it  negative. 

If  F s;  iiies  a control  or  test  function,  LN 
must  be  positive,  and  it  indicates  the  'aicbcr 
of  times  to  repeat  the  operation. 


BLOCK  Ll A I 4 

LOMMON/nMCCUM/NCOMP , NOMOD . NUCH  r 

c 

c STANDARD  NAMED  COMMON  FOR  CAMAC  SUBROUTINES. 

C 

NC  IMC:  NO.  OF  COMPUTER-LENGTm  WORDS  NECFuSAwr  TO  CON T A 1 \ ONE 
CAMAC-LENGTH  WORD. 

NOMOD;  NO.  OF  MODULES  (MAXIMUM)  IN  A CRATE. 

NOCRT:  NO.  OF  CRATES  PER  BRANCH. 

C 

DATA  NCOMP.  NOMOD. NOCRT /2 . 23 . 7/ 

END 


Fig.  1 


* 


1 . CMCBSC 

Purpose 

To  perform  a single  CAMAC  function  at  a single 
CAMAC  address  one  or  more  times. 

Cal  ling  Sequence 

CALL  CMCBSC ( F , B ,C ,N , AD, LN , DATA , Q , ERRORA) 

Arguments 

F:  CAMAC  function  code. 

B.  Branch  number. 

C:  Crate  number. 

The  crate  number  may  be  positive,  negative, 
or  zero.  If  it  is  positive  and  less  than  or 
equal  to  the  number  of  crates  per  branch,  a 
single  crate  operation  is  specified.  Crate 
number  = 0 indicates  a branch  controller 
function.  If  the  crate  number  is  between  -1 
ind  -127,  then  its  absolute  value,  taken  as 
i binary  number,  indicates  which  crates  are 
to  participate  in  a parallel  operation.  If 
the  nth  bit  from  the  right  is  i "1,"  then 
rate  n is  addressed  (e.g.,  C « -3  addresses 
< rates  1 and  2).  Crate  number  3 -126  indi- 
cates all  on-line  crates  are  addressed  i*’ 
paral  lei. 

N:  Station  number. 

Ai) j Subaddress. 

peat  and  word  length  specification. 

* F specifies  a data  transfer  function 
ai  or  write),  the  absolute  value  of  LN 
ftes  the  number  of  words  to  transmit; 


DATA:  Data  block. 

"DATA"  must  be  an  array  of  sufficient  length 
to  supply  or  to  receive  the  data  transmitted 
by  the  subroutine  while  executing  th«-  LAMA 
command.  "DATA"  supplies  data  during  writ* 
operations  and  receives  data  during  i * »d 
operations.  If  the  computer  word  length  i 
less  than  24  bits  and  LN  is  negative  tor  a 
read  or  write  function,  each  CAMAC  word  wi . 
be  stored  in  a contiguous  block  within  t • 
array  "DATA"  which  will  be  the  smallest  inte- 
gral number  of  words  required  to  hold  2-  bit  -. 
The  word  within  the  block  having  the  great-  ' 
address  is  filled  with  the  lowest  order  oit- 
of  the  CAMAC  word.  Computer  words  having 
successively  smaller  addresses  are  filled  with 
successively  higher  order  bits  ot  the  « AMA 
word  until  the  last,  which  is  filled  ut  wit! 
high-order  zeros  if  necessary*.  Note  that 
although  B,C,N,  and  AD  remain  cor.- rant  in  this 
subroutine,  the  computer  storage  address  is 
incremented  for  each  transmission. 

Q:  Q response  from  the  last  execution  of  the 
function . 

ERRORA:  Error  vector. 

Errors  detected  by  the  hardware  or  err  is 
detected  in  arguments  are  indicated  in  thi- 
array.  If  the  first,  word  of  the  error  vector 
is  set  to  0,  i.e.,  ERR0RA(1)*0,  no  errors 
were  detected.  If  ERR0RA(1)>0,  then  it 


/ 


\ 


r 
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contains  an  error  code,  and  the  foliowing 
three  words  may  contain  supplementary  infor- 
mation about  the  error.  The  codes 


1. 


3. 


5. 

6. 


7. 


Dataway  timing  error 
Branch  highway  timing  error  (e.g., 
offline  crate) 

Illegal  branch  number 
Illegal  crate  number  (e.g.,  rate 
number  greater  than  7) 

No  X response 

II  Legal  function  code  (e.g.,  not 
in  the  range*  0 to  31) 

Illegal  station  number  (e.g.,  not 
in  the  range  0 to  31) 

II  Legal  suhaddress  (e.g.,  not  in 
the  range  0 to  15) 

Illegal  value  of  LN 
Starting  CAMAC  address  is  less  than 
ending  CAMAC  address  (see  CMCASC) 
ERRORA  (.2)  contains  the  execution  count  at 
the  time  the  error  was  detected.  The  sub- 
routine stops  execution  when  an  error  occur*, 
and  does  not  attempt  to  complete  the 


II 


8. 


9. 

10. 


requested  number  of  fun  Lion  exc  uli  .. 
ERRORA  ( 3)  it.  used  is  a cumulative  er;'  r 
count.  Whem  ver  an  error  is  detected,  its 
value  Is  Increased  by  1. 

CMCSEQ 
Purpose 

To  execute  a single  CAMAC  fund. on  it  i su  • 
s i on  of  C AM AC  addresses. 

Ca 1 l ing  Sequence 

CALL  CMC SKQ (F , HA , CA , NA, ADA , LN , ^ . . , , _ i -u  i d 
Arguments 

F:  CAMAC  function  code. 

BA:  Branch  numbers. 

CA:  Crate  numbers. 

NA:  Station  numbers. 

ADA:  Subaddre.sses . 

LN:  Repe.t  . ->n.*  ar.  ; vor.:  length  sp*  . ui 
(+  - computer  length;  - - CAMAC  Kngt  .) 
DAT  A : Data  block. 

Q:  Q response  from  lust  execution  * t. 
ERRORA:  Error  vector.  (!ni  "or  array  et  U.-gti 
FORTRAN  Defi n i ti on 


SUBROUT  I ME  CMCSEQ(F,Ba .Ca ,NA , ADA, LN, DAT  a . 0, ERROR A) 
COMMON/CMCCOM/NCOMP  , NOMOt)  f NOCK  T 

INTEGER  F *BA.-<2).CA(2)  *NA(2)  ,ADA(2)  .l)ATA<2)  ,(j.EKr.H?VA(4  » 


bET  NUMBER  jF  WORDS  PER  TRANSFER. 


NW0S=NC0MF 
IFUN.GT  . 0 ) \wQS  = l 


SET  NUMBER  UF  EXECUTIONS. 


K = I A B S < L N ) 
IMK.EtM)  30  TO  30 


.OOP  IhrOUGH  CA.!  to  O'JrfRUU  T I NE  CMCBSC. 


DO  Id  I =1  ,K 
Ms  | •NWllS-NRfjS*l 

CAL  - CMCHSC ( F , 9A ( 1 ) ,CA ( 1 ) ,NA ( I) . ALA ( I ) , IS1GN( 1 r LN ) . DAT  A (M ) .0, 
ERROR  A ; 


CHECK  F.'K  ERROR. 


IF (ERRORA ( 1 ) .NE .0)  GO  TO  20 
10  CON  r ! NUE 


RETURN 

20  ERRORA ( 2 > = I 

return 

30  fc R R 0 K A ( 1 ) s9 
ERRURA (21=0 
ERRORA ( 3 ) - F R R 0 R A ( 3 ) ♦ 1 
RETURN 
E N if 


Note : 


Subroutine  "CMCSEQ’1  « ould  Jud  wt  . ! . 

as  the  fundamental  CAMAC  subroutine  us 
routine  "CMCBSC"  since  for  IN*1  <>r 
they  are  Identical,  in  function,  and  am  other 
sequence  of  CAMAC  operation  -:i  * m r . *• 
ed  from  them. 


I 


Fig.  2 


. ..»  . 


III.  O*  \,M. 


Purjgus. 

To  t*x«cut*-  i spe»  it  iod  CAMAC  function  in  the 
address  seal  mode. 

t.’  » J 1 i ng_  Scqut  nee 

CAl.I  * !'  ASC  t r . I ,C1  ,N  I . A I , BF , f'F  .NK , AF,  LN.DATA, 
ERRORA*. VEX) 


Argument s 

F:  CAMAC  function  code. 

U 

• . 


Ml:  Initial  station  number. 

AI : Initial  subaddress, 

BF:  Final  branch  number. 

CF:  Final  crate  number. 

NF:  Final  station  number. 

\F:  Final  subaddress. 

LN:  Exe  it  ion  limit  and  word  size  indication. 

(+■  = . ’T.puter  length;  - = CAMAC  length.) 

' .1A:  Dimensioned  array  for  data  sent  or  received. 
ERRORA:  Error  vector. 

Ni-X:  Nuiiber  f times  function  was  executed  with 

a Q*?l  r«  ;ponso,  (number  of  words  transmitted 
if  function  is  read  or  write). 


Address in g Rule 

Hie  specified  function  is  executed  first  at  the 
t.  r«  given  by  BI ,CI,NI ,AI . Then  If  the  Q response 
s 1,  the  subaddress  is  incremented  by  1 and  the 
index  , the  data  block  incremented  by  either  1 
r r he  miml  r of  computer  words  necessary  to  contain 
t AMV  word,  depending  on  the  sign  of  LN,  and  the 
un  i n • t.-i  at  this  new  subaddress.  If  the  Q 

~ msp  is  , lie  subaddress  is  set  to  zero,  the 
i hi  k index  Is  not  changed,  and  the  station 

i-  ••  r>. -rented  by  1 for  the  next  execution. 

t t ion  number  is  incremented  beyond  the 
t "N-.  ’Oh,"  it  is  set  hack  to  1 and  the  crate 
nnnh>*r  i in'  renented.  If  the  crate  number  is  incre- 
i : ■ . i the  value  of  "N’OCRT, " it  is  set  back 

’ j 1,  it  the  branch  number  is  incremented.  The 
r ; -1  exerutio  s of  the  function  is  limited 

» litude  of  LN  and  by  the  stated  final  values 
■ i"  t-Mress,  BFtCF,MF,AF.  Special  attention 

asr  • • 1 to  the  X response  in  the  address  scan 

1 • : i nodule  responds  with  Q*0,  it  may,  at 

give  X=1  or  X=U;  consequently,  in  this 
< - i'  > , the  X response  Is  ignored  when  the  Q 

response  Is  0. 


FORTRAN  Definition  (See  Fig.  i.) 

IV.  CHCRPT 
Purpose 

To  execute  a specified  CAMAC  fun  t i or  . i tie- 
repea  t mode . 

Ca  l l in&  S.-queru  e 

CALL  CHCRPT ( F , B ,(  , N , AD , LN , DATA , ERRORA ) 

Arguments 

F:  CAMAC  function  code. 

B:  Branch  number. 

C:  C rate  number. 

N:  Station  number. 

Ad:  Subaddress. 

LN : Execution  limit  and  word  size  indication. 

(+  = computer  length;  - * CAMAC  length.  » 
DATA:  Dimensions  arr  ry  for  data  sent  or  received. 
ERRORA:  Error  vector. 

Execution  Rule 

In  the  repeat  mode,  the  CAMAC  addre  s (u,C, 

N , A)  is  never  changed,  but  the  single  address  is 
expected  to  supply  many  words  of  data.  Q i-  .ed  *s 
a timing  signal;  Q= 1 indicates  that  the  previ* 
executed  function  succeeded;  Q=0  indicat-  th  *.< 
module  was  not  ready  to  accept  the  fun  i ion  and  :•  it 
the  controller  should  try  again. 

FORTRAN  Definition  (See  lig.  >*  • ) 

V.  CMCSTP 
Purpose 

To  execute  a specified  CAMAC  function  in  the 
stop  mode. 

Calling  Sequence 

CALL  CMCSTP ( F , B , C , N , AD , LN , DAT A , ERRORA , ‘ > 
Arguments 

F:  CAMAC  function  code. 

B:  Branch  number. 

C:  Crate  number. 

N:  Station  number. 

Ad:  Subaddress. 

LN:  Execution  limit  and  word  size  indication. 

(+  = computer  length;  - = CAMAC  length.) 
DATA:  Dimensioned  array  for  data  sent  or  r»  i • ivod. 
ERRORA:  Error  vector. 

NEX:  Number  of  times  function  was  e>  it.  d. 
hxe  ~ut ion  Rule 

In  the  stop  mode,  the  CAMAC  address  (B,C,N,\» 
is  never  changed,  but  the  single  address  is  expected 
to  supply  (or  accept)  many  words  of  data.  It  is 


ooo  ooo  ooo  ooo  o o o o o o o o ooo  ooo  ooo 
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SUBKOU  T INI  CMCASCIF . B I ,C I .M  . A I . BE .CF , NF . AF  . LN. Da  1 A .EhRORa , NF*  > 

COMMON/  Hf.rOM/NCUMH.NOMun.NUCRT 

INTEGER  T , R I .CI.AI  ,c)f  .(:>  ,AF, DA TA(0), ERROR A(4) 

I N T t OEM  fi , C . A . u 

c 

C SET  MAXIMUM  NuMat:k  ir  EXECUTIONS. 

K = I ABB ( LN ) 

SET  NUMBER  OF  WORDS  PER  DATA  TRANSMISSION. 

NRDS=NCOMP 

if(ln.gt.B)  n h n s = i 

CHECK  FOR  ARGUMENT  ERROR. 

If (K.EO.K)  GO  10  50 
IF  <hF .GT .8  I ) GO  TO  B 
IFIBF ,UT .Bi ) GO  TO  60 
IF (CF.GT .C I > GO  TO  B 
IFCCF.L1 -Cl > GO  TO  60 
IF  INF .GT .N I ) GO  TO  B 
IFINF.lT.NI>  GO  TO  60 
IFIAF.Ll .N! ) GO  TO  60 

SET  INITIAL  VALUES  uF  8.  C.  N.  A. 

B R = 8 I 
C = C I 
N = NI 
A = A I 

J IS  USED  To  INDEX  THE  ARRAY  "DATA". 

I COUNTS  I HE  NUMBER  OF  EXECUTIONS  OF  The  FUNCTION. 

J = 1 

I =0 

HA'  w ■ EXCEEDED  The  MAXIMUM  ALLOWABLE  Numreh  of  EXECUTI  >NS  r 
THIS  FUNCI ION? 

] 0 I F ( I . GE . K > GO  TO  00 

EXECUTE  THE  FUNCTION  ONCE. 

Call  CMCBSC(F.B.C.N,A,ISIGN(1,LN>.DATA(J>.0.FRR0RA> 

CHECK  FOR  ERROR. 

IF (ERRORA ( 1 ) . NE.0 > GO  TO  08 

CHECK  0. 

IF ( 0 . EO . 0 ) GO  iO  A 0 

I NCRF  Mr  N I THE  CORE  ADDRESS  INUEX  AND  THE  CAMAC  SUPAODRFSS. 


1 = 1-1 
J = J*NW[1B 
A = A ♦ 1 

IFTA.GT. IB)  GO  TO  40 


Fig.  3 

(Pnge  I of  2) 


t 


c 

C CHECK  FOR  END  OF  N A NGE  • 

C 

20  : F ( U .LT . BF ) GO  TO  10 
IF (B.GT .rfF  > GO  TO  30 
IF(C.LT.CF)  GO  TO  10 
IF (C.GT .CF ) GO  TO  30 
IF (N.LT.NF  > GO  TO  10 
IF ( N.GT . NF ) GO  TO  30 
1 F { A .Lb  . AF  ) GO  TO  10 
GO  TO  30 

B.C.N.A.  UR  I HAS  EXCEEUEO  LIMIT;  HALT  6XECOTION  OF 
CAMAC  FUNCTION. 

28  II ( CERROhAI 1 ) .EU. 5) .AND. (U.EQ.0) >GO  TO  38 
30  Nt X = 1 
RETURN 

GO  TO  NEXT  MODULE 

38  ERRORA ( 1 ) =0 

ERR0RA(3)=ERR0RA(3)-1 

40  A :0 
N = N ♦ 1 

IFIN.LE. NOMOO)  GO  TO  20 

GO  TO  NEXT  CRATE. 

N = 1 
C = C*1 

IF (C .Lb . NOCR T ) GO  TO  20 

GO  TO  NEXT  BRANCH. 

C = 1 
B = B*1 
GO  TO  20 

ERRORS  DETECTED  IN  ARGUMENTS. 

1.  LN=0 

80  ERRORA ( 1 ) =9 
ERRORA ( 2 ) =0 
ERR0RA(3)=ERR0RA(3>»1 
RE  TURN 

2.  (Bl.CI.Nt.Al)  IS  GREATER  T H AN ( 8F , CF , NF , AF ) 

60  ERROR  A ( 1 ) : 1 0 
RETURN 
END 


Fig.  3 

(Page  2 of  2) 
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subroutine  cmc rp it f.b.c.n.ao.ln, data, errora) 

COMMON/ C MCCOM/ NCOMP, NOMOO. NOCRT 

integer  f,b.c,au.daia<2),erroka<4>,u 

c 

SET  no.  Of  COMPUTER  WORDS  PER  TRANSFER. 

C 

NwUS=NCOMP 
IF(lN.GT.D)  N w I)  S = 1 
C 

C SET  NUMdER  Of  EXECUTIONS. 

C 

K = | ABS( LN ) 

C 

c check  fur  zero. 
c 

IFTLN.EU.0TGO  TO  40 

c 

SET  EXECUTION  PARAMETER  FOR  "CALL  CMCBSC" 

C 

L = I S I GN ( 1 , L N ) 

C 

C INITIALIZE  LOOP. 

C 

J = 1 
1 = 0 

10  IF  < I .GE . K ) RETURN 
C 

C INCREMENT  Tm.LT 

C 

1 = 1*1 

c 

C ATTEMPT  TO  EXECUTE  FUNCTION. 

C 

20  CALL  CMCdSCT F , B.C.N, AO,L , DA  I A ( J ) , Q . ERRORa ) 
IF(ERRORATl) .NE.0)  GO  TO  30 
IFTQ.EO.0)  GO  TO  20 
C 

C INCREMENT  STORAGE  ADDRESS  AND  LOOP  BACK, 

c 

J=J+NWDS 
GO  TO  10 
C 

C ERROR.  STORE  EXECUTION  COUNT  IN  EHRORA ( 2 ) . 

C 

30  ERRORA ( 2 ) = I 
RETURN 
C 

C LN=0.  RETURN  ERROR  9 . 

C 

40  ERRORA ( 1 ) =9 
ERRORA ( 2 ) =0 
EHR0RA(3)=ERR0RA(3)*1 
RETURN 
END 


assumed  able  to  supply  or  accept  a word  of  data 
whenever  the  controller  addresses  It,  until  the  block 
is  exhausted.  The  controller  may  terminate  the 
process  if  the  number  of  executions  exceeds  the  limit 
given  by  the  magnitude  of  LN , or  the  module  may  term- 
inate the  process  by  responding  with  Q=0.  Q=0  implies 

that  no  data  was  sent  or  accepted  during  the  CAMAC 
cycle  for  which  it  is  the  response.  Q=1  indicates 
normal  execution  of  the  function. 

FORTRAN  Definition  (See  Fig.  5.) 


VI.  CMCLl'P 

Purpose 

To  execute  a specified  CAMAC  function  at  a 
hierarchical  sequence  oi  rddresses  with  the  option 
of  skipping  certain  portions  of  the  sequent  e based 
on  the  Q response. 

Cal  1 i_r Seqi a • nee 

CALL  CMCLUP (F , bA , LB , CA , LC , NA , LKN . ADA . LAD , LN . 
DATA , Q , QON , ERRORA , NEX ) 


1 

1 


4 


SUSROUT I ME  CMCSTPTE.S.C. N.AU.LN.DAT A. ERROR  A, NEX) 
COMMON/ CMC COM/NCOMP .NOMOD.NOCRT 
INTEGER  E,B,C,aD.DATA(2>  .ERRORA  ( A ) . G 
C 

C SET  NO,  OF  COMPUTER  WORDS  PER  THANSEER 

C 

NWDS=NCOMR 
1 E ( LN . G T . 0 ) N W OS  = 1 
C 

C SET  NO  OE  EXECUTIONS. 

C 

KslABS(LM) 

I E ( K . EU . 0 ) GO  TO  30 
C 

SET  EXECUTION  PARAMETER  FOR  "CALL  CMC8SC" 

C 

L=IS IGNtl.LN) 

C 

C INITIALIZE  LOOP. 

c 

J=1 

1=0 

c 

C TEST  EUR  END  UE  EXECUTION. 

C 

LSI  IE  U .GF  .tO  RETURN 
C 

c increment  execution  tally. 

c 

i = i*i 

c 

c attempt  to  execute  function. 

c 

CALL  CMCHSCt  E ,B,C,N,aD,L.DATa(J) .0, ERRORA ) 

IE (ERRORA ( 1 ). NE ,0)  GO  TO  20 
IE  ( Q , EG) . 0 ) GO  TO  20 
J- J*NWI)S 
GO  10  10 
C 

ERROR.  SET  EXECUTION  COUNT  IN  NEX  AND  EXIT. 

C 

20  NE  X = l 
RETURN 
C 

C ERROR:  LN  = 0. 

C 

30  ERRORA ( 1 ) =9 
ERRORA ( 2 ) =0 
ERR0RA(3)=ERR0RA(3)*1 
GO  TO  20 
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A rguments 

I : CAMAC  f un c t ion  code . 

BA:  Branch  numb or  array. 

LB:  Number  ot  branch  numbers. 

CA:  Crate  number  array. 

LC:  Number  of  crate  numbers. 

Na:  Module  number  array. 

1 ,KN : N umbe r o f modu 1 e numb e rs . 

ALA : Subaddress  array. 

I. AD:  Number  of  subaddressc  . 

LN : hxi  ut ion  limit  and  word  size  Indication. 
(+  = computer  length;  - = CAMAC  length.) 

DATA:  Data  array. 

Q:  response  of  last  execution. 

QON : Control  argument  indi<  itlng  whether  or  not 
to  use  Q response  for  skipping  addresses. 

I means  use  l^;  Q means  ignore  Q. 

F.RRORA:  Krror  sector. 

NKX:  Number  of  times  the  function  was  executed, 
or  the  number  of  times  the  function  was 
executed  with  a Q= 1 response  if  QON-1, 
(.number  of  words  transmitted  for  read  or 
write  functions). 


Execut  ion  Huh 

"BA,"  "CA,"  ".NA,"  and  "ADA,"  are  enrh  om- 
dimensional  arrays  containing  list.1-  of  brar  r.,  crate, 

module,  and  s iba  id  re  >s  nuflbi  n r<  ipe<  t 

program  execute  or  attempts  to  • ut.  , rv 
function  at  each  CAMAC  address  which  can  be  formed 
by  combining  the  elements  of  these  array: . It  h*  gins 
by  choosing  the  first  element  ol  each  array  and 
advances  the  address  by  choosing  the  next  element  f 
the  subaddress  array,  etc.,  .f  anning  the  sub  • Hr  . 
most  frequently,  tin  module  number  - next  , . t . , u ; » . . 
the  last  element  of  ea«.h  array  is  used.  If  Q'H  = l, 
a Q=0  response  will  uuse  the  module  index  to  advance 
and  the  subaddress  index  to  bt  set  to  1. 

. : fcN  ej  . ; ■ et  Fig.  6. 

VI 1.  REFERENCES 

’CAMAC:  . trumentat 

D'ita  Handling,"  TID-25875. 

2.  "CAMAC:  Organization  of  Multi -i  rate  Sy 

TID-25876. 

3.  "Supplement  to  CA MAC  Instrumentation  : r.  v 

Specifications,"  TID-25877. 
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c 
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c 

c 

c 

c 


SUUROUT  INb  CMCLUP(F.BA,L8,CA,LC.NA.LKN.ADA,'.  A'I.LN.DATa.U.U  \. 

1 ERRUR A . N6  x ) 

iMMUN/CMCCOM/NCOMP , NOMOD.NOCR  T 

I NT  E .ER  F . BA  t LB  ) . CA  ( LC  ) . na  ( LKN  ) . ADA  ( L AD  ) . DATA  ( 2 ) , Q , OON.ERR  PA  ( A ) 

SET  NUMBER  Or  C0MPU1ER  ROROS  PER  TRANSFER. 

NwDS=NCUMP 
IF  (L'J.GI  .0)  NRUS=t 

SE  t EXECUT ION  L IM l I . 

K = | ADS( LN> 

CHECK  LIMIT  FOR  ZERO. 

IF(K.EO.U)  GO  TO  60 

SET  EXECUTION  PARAMETER  FUR  "CALL  CMCBSC”. 

L = I S I GN  < 1 » L N ) 

INITIALISE  INDEXES  FOR  EXECUTION  COUNT  AND  DATA  TRANSFER.  I 
COUNTS  EXECUTION  OF  F:  J INDt/ES  "DATA". 

1=0 

U=1 


Fig.  6 

(P.’ig a 1 of  2) 
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5FT  UP  TOUR  NESTED  DO’S  TO  EXECUTE  THE  ADDRESSING  ALGORITHM. 

DO  40  Mb  = 1 . L H 
DO  <0  MC=1.LC 
DO  40  MN  = 1 , LKN 
DO  30  MAOsl.LAD 

ATTEMPT  10  FXECUTE  FUNCTION  ONE  TIME. 

call  cmchsc<  f ,ba <mb>  ,ca<mc>.,na <mn>  , aDa(mad>  ,l , datat  j>  , o,  error  a ) 

IS  0 BEING  CHECKED? 

I F ( UON . EO . 0 ) GO  TO  20 

TES.  |f  >J  = 1 . PROCEED  NORMALLT.  IF  Q = 0,  IGNORE  X RESPONSF  AND 
BRANCH  TO  END  OF  N LOOP. 

IF <0.£ 0.1)  GO  TO  20 

IF < IERRURa ( 1 ) . EU. 5 > . OR . < ERRORA ( 1 ) .EO.0) ) GO  TO  40 
GO  TO  70 

INCREMENT  DATA  INDEX  AND  EXECUTION  COUNT.  TEST  EXECUTION  LIMIT. 

20  1=1*1 
J= J*NRDS 

I F ( 1 .GE.K)  GO  TO  50 
DO  NORMAL  ERROR  CHECK. 

IF (ERRORA(l) .nE.0)  GO  TO  70 
END  OF  SUbADDRESS  LOOP. 


30  CONTINUE 

END  OF  BRANCH,  CRATE.  MODULE  LOOPS. 

40  CONTINUE 

SET  EXECUTION  COUNT  AND  RETURN 

50  NE X = I 
RETURN 

L N = 0 . GIVE  TYPE  9 ERROR. 

60  ERR0RA<1>=9 
ERRORA ( 2 ) =0 
ERRORA ( 3 ) =ERRORA ( 3 ) *1 
RETURN 

ERROR.  SET  ERR0RA(2l  TO  EXECUTION  COUNT. 

70  ERRORA  < 2 * = I 
GO  TO  50 

END 


Fig.  6 

(Page  2 of  2) 
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STANDARD  SOFTWARE  FOR  CAMAC  - COMPUTER  SYSTEMS 


Chai 


by 

I.  I- . Hooton, 

"r.an  cf  the  ESOKE  Software  Working  Group, 
A.E.R.E. , Harwell,  England. 


-oatures  of  the  CAKAC  -nr.guage  of  interest  to  the 
application  programmer  are  briefly  described.  A method  of 
implementation  via  the  CAKAC  intermediate  language,  IKL,  is 


C*  2.  E»  C U L>  o £.*  Q • 


Appendices  give  examples  of  statements  in  the  CAKAC 
Language  and  of  translations  of  typical  statements  into  I HI 


introduction, 
j.  background. 

p.  features  of  the  CAKAC  Language, 
h.  The  concept  of  the  Virtual  Controller. 

р.  Implementation. 

с . Acknowledgements . 


appendix  . . Examples  of  CAKAC  Ear.  uage  Statements 


. . .....  . ....  .....  . ...  ' i ] . Jranslat: 


• n EV.G  17/72 
-cr  1 >72. 


j 


"lit  Software  Working  Group  of  the 
Committee  has  published  a "1  reposal 
. . C .MAC  Language"  in  the  form  of  a 

pt  Lfication.  Th<  pj  . . 

includes  an  appcnaix  with  two  extensive 
examples  of  the  use  of  the  language,  but 
not  otherwise  directed  specifically  to 

ino  applicttoioa  prograiaiiicr. 

t..is  pcips,*r  tiio  oux**^  ■*■  ais- 

ouj;  i**  oraer  to  snow  tr.c  need  :"or  fan 

.....  ......  i . L'his  ii  1 b; 

description  ol  some  oi  the  -acilitica 
avail  able  to  the  application  programmer 
.,.•1  t..s  fit:al  section  discusses  a method 
ernen  at  ion.  Examples  of  sp<  :ific 
atat  -.meats  in  the  language  are  given  in 
. a ee : . .. x 1.  translation  oi  tyoica* 

l . ...M  r.ts  .nto  a more  explicit  language 
is  discussed  in  Appendix  2. 

since  the  "proposal  for  a CAMAC 
L ingua  e"  has  been  gublis.-ied  expressly 
oita::.  comments  the  iinal  version  nay 
differ  from  that  described  here. 


2 . mm  niuf.  : 


■ . . .er  in  CAKAC  ..aruware  is 
local- a at  a suhuduress  (A)  of  a station 
(; ,j  ir.  a crate  (C)  on  a Drar.ch  (B) . Its 
CAMAC  ouaress  is  the  combination  oi'  the 
..ui.iencal  values  -Or  eacr*  oi  the  .our 
compon  ats  £,  C,  N and  A.  Tne  action  to 
•„e  p--r  formed  is  specified  by  tne  GaM.-.C 
! :.:.ciion  core  (F)  directed  to  tne  C«KaC 
address,  every  action  generates  a 
Command  Ac. epted  (a)  signal  from  Ca.--.-vC 
md  rua;  also  generate  - Response  (.Q)  sig- 
Certain  functions  also  cause  up  to 
g4-b.  ..  of  data  to  be  read  from  or  written 

uO  Citi'i.'tO  • 


-t  c «au  s ( i t r.e  fAiiiCUiit  ot  mioxiiui*” 
required  for  a single  CA.-..-.0 
■ji  '-ration  the  hardware  v.i.ich  couples 
;a,\.v.  to  tne  computer  contains  a number 
of  p. i asters.  The  disc n cut ion  o.  the 
li. f ore.  . 1 1 on  between  tneso  registers  is 
t..  uj.g  arranged  to  suit  t.'.e  r.aruware  o. 

tor  exaii  le . in  < >ne  com- 
t.erc...iiy  available  coupler  the  crate 
■ . j i Hu  trie  function  coce  ft  / a.  o 
_ • : u e. .ii.  r.e. ci  ir.  om  i egis .er . 

register  holes  the  hign-orde-r  uata 
bits  C‘V  to  2h),  a:iu  c,  N and  A form  part 
of  .’mV.,  instruction  .i.ii'V  to  the  low* 
r a nits  « fhis  i vei  e 1 fi- 

de..;. use  c.f  the  computer  Hardware, 

-]_•  ....  a sequence  oi  nstrue- 

tioi.s  which  aa.iross  the  same  action  to 
_,.,t  i-epi.-ters  in  a ccuu.’.on  crate. 


operations  for  suer,  a coupler  is  to  ■r.'.e 
specific  instructions  within  the  i .- 
t.ori  program  •»-aich  -oac  the  r.pp:  . te 


. ...  giv  ..  the 

iorr..ancc 

ir.  execution  for 

two 

rCi.K  .'.a  . 

v 

t:  . ova-rn-aus  are 

K:2-Zi 

ir.ic-.  •-  l.7.1 

- -A  ^ 

L*  c."  C vl  2 i > * j | 

only  cnose  : .-atu 

.equir -u  .ire 

used  for 

each  op. ration. 

ror 

C'Xms'  . c , - I 

no  action  ic  a-  te  tax or.  tne  ctat--  oi 
the  Response  is  not  tested. 

The  mayor  a.sadvantage  cl  t ms  metres 
is  that  it  requires  tne  application 
: rogr.-n.eer  to  have  dec.. lee  .-.rawledg-.  si 
the  coupler.  Hi  must  know,  for  e:  • 
tne  different  sequences  for  Re&c  u..u  ..'rite 
operations  ana  tne  effect  of  lo-bit  or 
24-bit  data  transfers  on  tne.:..  — t 

know  how  to  access  C„  a.nc  X,  and  lr.  : ar- 
ticuiar  he  must  convert  the  CAMAC  EC.‘ .. 
a dcr  •.  into  t pro]  ...  ...  . , 

he  is  cooing  for  a vary  specific  caesme. 

This  difficulty  may  be  cvercc  :e  by 
providing  ei.ner  a set  ol  macro  c -s 
which  generate  the  appropriate  in-line 
cone  or  a set  of  subroutines  as  a enver 
package  for  the  coupler.  Ir.  eitr.-er  can. 
the  set  may  be  implemented  oy  ar.  expert  .. 
the  computer-coupler  combination  ar.  - : 
made  available  to  application  pro-tra.  m. 

Effectively  the  macro  or  subroutine 
Call  defines  wnat  is  to  ha: pen  in 
CAMAC  part  of  the  total  system  a:.i  is 
independent  of  tne  ... .-uranism  in  mo  ecu  . - 
however,  the  call  must  define  explicit.y 
the  n.ecr.anism  within  C A f . . r or  ex..  . - , 
tne  demand  signal  m a ..rate-  Centro-. er 
Type  A is  enabled  by  means  of  CAMAC  .unc- 
tion code  (26)  to  subadares.-.  (1C;  o. 
station  (JO)  in  the  crate  (e.g.  or.: 
branch  1),  and  a suitable  instruction 
would  be 

CTkL  26  H, 1,2, JO, 10 

hi.  alternative  way  of  defining  precise _y 
the  sa:..e  requirement  -s 


ENABLE  CAATEDLXAvio 

The  first  example  is  from  a fully 
explicit  language,  uesigsea  Jar  »a-e 
ii.-plem-nta:  ion  (for  example  by  macros/, 
and  the  second  ir  from  a langur. , . cen  :.«a 
for  ease  of  unuc.  . anumg  ay  t.’.e  ..rogram- 
ri.er.  Thus  the**e  is  a need  for  two 
different  -ui.j.’-a.vs  having  tne  same 
facilities.  The  1-  CAE  software  working 
.roup  recognises  tms.  Tne  . cond  s.  .tt.- 
..ont  is  from  the  CAmC  La.  u:  e ar.c  tr.e 
film  t *o  from  a CaMAC  intermediate 
..  a.  ■ , . ...  • ■ ■ . the  ■ - a 


I 
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• n to  cr.-bl  • the-  ..  re  .r-ir.n.or  to 

quireum-nt  for  ouch  operation 
tl.c  c.u-1:  .»  mechanic:.,  in— 

- ^ ■*  lii  'ICJa  “ItiCi  t»C»  v’C.' 

t-.r::::;,  t in  ea^h  :•  contains 

- ---  -h  • '..'or-aiicn  required 

- - - 1 ■ • . -.. . Both  _ ...  have 

- ■•-  ■-  •'  .c  ilities,  tho  igb  - • y 

'-ore  so  expi-.-:..,  then.. 


■ . ..  •• 


.r.  ■ -.;o  u.  . ir.-tion  of  t;..-  CA..AC 
\ -.  " • --••  run  • features  are  expres- 
i;;  transfer,  control,  branching  and 
utivw  . ..  temer.  . . fer  tateraents 

-°-l  '•'it..  reading  d..:a  or  writing 

1 •■  ■■ ch  . . merit  . retries 

--  . action  to  be  performed,  the  CA.KAC 
. ■ - ..s  -..c  — reference  to  the  computer 
. • - ■ t ....  . nc  t : nc 

. emery  reference  ar.a  may  be  addressed 
.ifr.i  r to  a b. C address,  for  example  to 
tear  a ■■  'ist  .- , or  * the  1 r,  for 
e>;:  --n-blo  demands,  branching 

nt  ional,  conait  ion- 

~.j-  ci.  one  state  o:  the  LAK  or  status  at 
a L/...C  address,  or  com  .aioi.al  on  flags 
ir.  t..  .a -pier,  Executive  statements 
r..l-.e  primarily  to  the  scheduling  of 
taid-is . 


- ■ actions  to  he  performed  in  the 
o...  ...  r.  . :r...y  be  defined  by  the 
lur.e . i or.  eoce,  e.g.  ?(C);  by  a 

. r ... 

-e.ir.o-  - . rnfco- , e.g.  Coil. 


*•■*'-■  C address  may  . - contained 
ui. state. -.ent  or  ...-Id  i.;-.  a computer 
-OCaf.j.;  poir.iea  to  by  the  state;.. -nt. 

------  ..  .ter  . permits  run— time  me  - 

- - - - - h ...  address.  aduresr 

• . “ • ratten  m tr.e  EC. -A  form  or  as  a 

■ ■ ■ - by  i..  user.  ...  ..  r -. . : 

■is  • . . .vide  of  the  same  group  of  CA.'f.C 

. . iu  u-citi  to  declare  ..  name 

- - ?.  The  for  . ■ . - : 

wbt  -her  • a raj  . in  iis- 

iri  ucio..  cf  abi.ressc-s  (described  by  a 

— or  'nether  it  is  uniform  and  may  be 

b — reiser,  ing  the  ...  nents 

- (for  example  by  the 

- - n men.  of  operation) . 


at  irr-  ;u.  .r  int.  rv.»l.-.. 

drite  stater.  :.ts  ray  c -stair.  th< 
actual  value  (literal,  that  is  to  be 


tr  ft  rre . t 


.rans.er  a..;  control  statements  .-  .y 
. ns. use  a repeat  qualifier  giving  tr.. 
number  cf  time's  the  operation  is  to  be 
; rfor-.  s before  executing  the  :.  /.t 

S • • fc  ;..  t hies  block  .-  : 

' i . ieclara 

nt  allow  the  standard  forms  of  , res- 

addre-- 


ponse  to  be  associated  with  IAKA _ 
ses  and  then  used  in  transfer  and  control 
statements. 


Demand  han-lmg  is  s.m.piifie-d  by  the 
xnngua;  e.  statements  are-  provided  f .:  r 
spocifying  the  various  nochani:..  a avail- 
r-- - in  - mu  for  linking  demands  wit.-, 
labelled  statements  or  to-xs. 


appendix  i gives  some  examples  cf 
me  types  of  statement  that  may  be  made  ir. 
t..e  tnX/iC  Lt;.  "...  -e . 


--C  • Of 


• h e spec.,  ication  of  the  lar.  yuage 
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Appendix  2. 

Examples  of  CAMAC  to  IML  Translation 

Since  both  the  CAMAC  Language  and 
the  intermediate  language  IML  have  still 
to  be  revised  the  final  versions  may 
differ  from  those  shown  here. 

In  these  examples  the  CAKAC  Language 
statements  are  similar  to  those  explained 
in  Appendix  1 and  make  use  of  the  same 
declarations. 


CAKAC: 


READ  REG  LOCN 


IML:  READ  0 H, 1,2, 1,0  V, 16, LOCN  N,N,N 

The  IKL  statement  consists  of  the 
following  fields: - 

Statement  class  READ 

CAKAC  Function  Code  0 
Hardware  Address  H,  1,  2,  1,  0 
(B,  C,  N,  A) 

Software  Reference  V,  16,  LOCN  (a  var- 
iable of  16-bits) 

Condition  Code  N,  N,  N (N  = null) 
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IML:  i*AD  0 H, 1,2, 3,0  A, 2 

READ  0 H, 1 ,2,7,0  A, 2 

READ  0 H, 1,2, 2,0  A, 2 

READ  0 H, 1,2, 5,0  A, 2' 

IKL  expands  the  CAMAC 
four  statements  inserting  t! 
values  from  the  hardware  am 
arrays  into  each  statement. 


CAKAC:  REPEAT  (64)  READ  BUF3 

IML:  READ  0 H, 1,2,18,0  L,l6, 
LISTFULL,R,64  ' 

The  conditions  are: 

transfer  if  Q = 1 

jump  to  LISTFULL  if  Q = 0 

repeat  64  times 


CAKAC: 


.(RITE  LOCN  REC 


IKL:  WRITE  16  H, 1,2, 1,0  V,16,L0CN  N , N , N 

Write  statements  have  similar  fields 
to  read  statements. 


CAMAC: 


CLEAR  REG 


IKL:  CTRL  9 H, 1,2, 1,0  N,N 

Control  statements  do  not  require 
the  software  reference. 


CAMAC:  IF  LAE  REG  GOTO  LABEL 

IML:  CTRL  3 H, 1,2, 1,0  N,d^, LABEL, N 

The  condition  is  'If  Q = 1 jump  to 

• «DVT  I 


CAMAC: 


EN,.  B LEI  NT  MY  CRATE 


IML:  CTRL  26  H, 1 ,2,50, 10  N,N,N 

The  IML  statement  uses  function  code 
26  at  subaddress  10  of  station  50  in  the 
crate  MYCRATE  as  specified  for  Crate 
Controllers  Type  A. 


CAMAC:  READ  DEVICES  (1:4)  ARRAY  (1:4) 
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SECTION  IV 


REPORT  ON  REAL-TIME  EXTENSIONS 
AND 

IMPLEMENTATIONS  OF  REAL-TIME  BASIC 


The  European  Regional  Branch  of  the  Industrial  Real- 
Time  BASIC  Committee  made  as  its  first  order  of  business  a 
review  of  the  existing  sets  of  extensions  to  the  BASIC 
language  now  in  use  or  under  development  by  the  various 
vendors  and  use.  This  new  document  has  not  yet  appeared  in 
the  Workshop  Minutes  but  is  produced  here  anyway  because  of 
its  importance  to  the  field. 
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PRSC2DIIC  PA3t i I$LANK- NOT  FILMED 


Foreword: 


The  increasing  use  of  small  computers  in  real-time  applications  has 
resulted  in  the  requirement  for  an  appropriate  programming  system. 
Simple  programming  languages  such  as  BASIC  have  been  widely  used  to 
meet  this  need.  The  language  has  been  extended  to  include  statements 
handling  real-time  events  and  process  peripherals.  Implementations 
utilising  such  extensions  are  commonly  referred  to  as  real-time  BASIC. 

This  paper  compares  and  discusses  various  real-time  extensions  and 
suggests  guidelines  for  a unification.  It  is  a working  document  and 
is  intended  to  stimulate  further  discussion.  In  particular  the 
examples  used  present  semantic  interpretation  and  should  not  be 
considered  to  be  a syntax  definition. 

The  paper  is  intended  to  inform  users  and  implementors  of  current 
developments  in  real-time  BASIC.  It  is  the  aim  of  the  group  to 
produce  more  definitive  recommendations  in  conjunction  with  users 
and  other  interested  bodies. 

Comments  from  any  source  would  be  most  welcome  by  the  group  and  should 
be  addressed  to  any  member  listed  in  appendix  V. 


1.  Objectives  for  a simple  language  to  program  small  real-time  computer 
systems. 

2.  How  to  reach  these  goals. 

3.  Dartmouth  BASIC. 

4.  Functional  needs  for  real-time  extensions. 

Appendices: 

I.  Dartmouth  BASIC  syntax. 

II.  Comparison  part. 

III.  Literature 

IV.  User's  guide  . . . 

V.  Address  list 


1.  Introduction: 


The  achievements  of  semiconductor  technology  have  made  it  possible  to  use 
mini  and  micro  computer  systems  for  RT  problems.  In  contrast  to  large 
process-control  systems  which  run  autonomously  and  restrict  user  inter- 
actions we  are  faced  with  computer  systems,  that  are  used  as  a tool  by  a 
technician  or  scientist  requiring  intensive  interaction  and  great 
flexibility. 


Some  typical  application  areas  for  such  systems  are  test  and  diagnosis, 
control  of  industrial  processes,  experiments  and  teaching  systems.  All  of 
these  require  the  user  to  perform  multiple  test  runs  and  he  must  have  the 
capability  to  make  modifications  easily. 

Flexibility  often  means  increased  software  costs  while  hardware  costs 
continue  to  decrease.  The  software  system  become  more  complex  and  the 
training  costs  for  programmers  rise. 


■W 
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In  addition  to  that,  even  experienced  programmers  need  a great  amount  of 
time  to  be  able  to  program  technical  and  scientific  applications.  This 
causes  delay  and  difficulties  and  hinders  quick  solutions.  This  problem 
only  can  be  solved  by  the  user  writing  programs  himself.  But  for  this 
purpose  he  must  have  a programming  system  with  a language  easy  to  learn  and 
to  remember  and  producing  results  immediately. 

The  computer  system  as  a tool  should  provide  strong  support  for  the  user. 

The  level  of  the  language  should  be  high  (similar  to  FORTRAN)  and  the 
language  elements  should  allow  apolication  to  a large  class  of  problems. 

The  syntax  should  be  simple  and  should  allow  immediate  diagnostics.  There 
should  not  be  complex  relationships  between  the  statements. 

Working  with  the  computer  should  be  done  in  a dialogue  form.  The  system 
control  commands  (such  as  saving  programs)  and  the  editing  commands  (such 
as  deleting)  should  be  powerful  but  as  few  as  possible.  Furthermore  U 
must  De  simple  and  fast  to  pass  from  editing  a program  to  running  it  and 
back. 

Immediate  execution  of  single  statements  or  groups  of  statements  should  be 
possible.  A tracing  facility  should  exist  for  debugging  purposes.  Values  of 
variables  should  be  readable  and  changable.  The  user  should  not  be  forced 
to  call  and  start  system  programs  such  as  an  editor  or  loader  but  ratner 
the  system  should  be  a unified  whole. 

Let's  summarize  the  objectives  such  a system  should  be  able  to  meet.  It 
should  allow  quick,  portable  solutions  of  simple  problems  for  beginners  and 
non- programmers  and  it  should  be  easy  to  implement  in  order  to  achieve  wide 
acceptance.  The  latter  is  especially  important  for  the  education  of 
newcomers  to  the  field  of  real-time  computer  control. 
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2.  How  to  reach  these  goals 


2.1  Compiler  versus  Interpreter 


A programming  language  is  used  to  describe  and  specify  the  program  flow  to 
solve  a problem.  But  the  language  itself  must  be  implemented  by  translating 
it  into  the  code  of  the  host  machine.  We  try  to  describe  three  ways  of 
implementing  BASIC.  There  are  hybrid  forms  in  existence  but  most  of  them 
are  near  to  one  of  the  following  types. 

A)  Compiler:  The  processor  which  "runs  a program"  is  executing  machine 
instructions,  i.e.  at  runtime  the  program  exists  as  a sequence  of  machine 
instructions.  It  is  the  task  of  the  compiler  program  to  check  the  syntax 
and  to  translate  the  BASIC  source  program  into  machine  code.  This  machine 
code  is  then  executed  by  the  hardware  of  the  processor. 

Because  BASIC  is  not  block  oriented  it  is  easy  to  implement  with  a 
compiler.  Most  of  the  syntax  checks  can  be  done  when  the  lines  are  typed 
in.  This  is  important  when  using  intelligent  terminals  where  the  terminal 
can  make  the  line-syntax  check  and  only  send  correct  lines  to  the  main 
system  for  compilation.  The  compilation  time  is  thus  reduced.  But  for  any 
changes  in  the  program  the  entire  program  has  to  be  recompiled. 

B)  Interpreter : BASIC  can  be  implemented  by  using  an  interpreter,  a program 
that  examines,  at  run-time,  each  line  of  the  source  program  starting  with 
the  first  and  calls  the  appropriate  machine-code  routine  to  perform  the 
action.  The  interpreter  in  a way  executes  BASIC  statements  directly,  i.e. 
looking  at  the  system  one  can  speak  of  a BASIC  computer.  In  fact  a virtual 
BASIC  machine  is  built  by  software. 

The  translation  of  the  source  code  at  run  time  causes  a significant 
reduction  of  execution  speed.  The  program  coded  in  the  higher-level - 
language  code  (the  source  code)  is  more  core  efficient  than  machine  code 
but  machine-coded  programs  are  able  to  run  without  the  interpreter 
routines. 


Micro  programs  are  an  interesting  form  of  interpretive  execution.  In  this 
approach  the  processor  is  executing  primitive  instructions  at  high  speed 
from  a special  high  speed  memory.  Sequences  of  such  instructions  are  called 
by  the  instructions  of  the  main  memory  which  are  generated  by  the  inter- 
preter. If  the  highspeed  memory  contains  routines  which  execute  BASIC 
statements  as  a sequence  of  primitive  instructions  one  has  implemented  a 
direct  BASIC  source  code  executing  machine  which  is  much  faster  than  the 
software  version. 

Most  new  interpreters  translate  the  statements  into  "intermediate  code"  to 
improve  execution  speed.  This  means  that  the  source  code  is  changed  into  a 
form  which  allows  faster  execution  but  still  holds  all  the  information  to 
reclaim  the  source  code  for  listing  purposes.  The  user  thus  dea's  only 
with  source  code. 

Incremental  compiler:  The  line  orientation  of  BASIC  makes  it  possible  to 
compile  it  line  by  line  without  much  loss  of  efficiency.  (This  would  not  t>. 
true  for  block  oriented  languages  like  ALGOL.)  The  program  is  translated 
line  by  line  into  machine  code  and  stored  by  placing  the  starting  locations 
into  a list.  When  mocifications  or  deletions  of  lines  are  performed  this  is 
done  by  changing  the  list. 

Before  the  program  is  run  one  must  check  the  statements  which  influence 
other  lines  i.e.  nesting  of  FOR  NEXT  loops,  GOTO's,  GOSUB's  etc.).  This 
check  is  usually  triggered  by  the  RUN  statement.  It  is  possible  to  design 
the  incremental  compiler  such  that  the  emitted  code  with  its  forward 
reference  linkage  and  starting  address  list  can  be  executed  without  run- 
time support  making  its  r un-time  efficiency  close  to  that  of  an  ordinary 
compiler. 

A difficulty  arises  from  the  fact  that  the  sourcecode  car.  u be  reclaimed 
from  the  compiled  code  so  that  one  has  to  keep  a source  code  copy  of  the 
program  in  addition  to  the  compiled  code. 

The  incremental  compiler  usually  needs  background  storage  but  by  combining 
advantages  of  compiler  and  interpreter  it  is  a powerful  type  of  imple- 
mentation. 


2.2  Commands 


Extensions  towards  operating  system 

When  writing,  testing  and  running  programs  the  system  should  support  the 
user.  For  this  purpose  system  commands  are  added  so  that  the  user  gets 
familiar  with  the  language  and  the  system  at  the  same  time  and  need  not 
learn  several  different  system  programs. 

A)  Editor  commands 

All  commands  which  are  needed  for  editing  like  insert,  delete,  list  etc. 
should  be  contained  in  the  language. 

B)  Execution  commands 

The  starting  or  stoping  of  a program  or  part  of  a program,  the  execution  of 
single  statements,  the  display  of  calculated  or  defined  variables  after  the 
program  has  halted  and  similar  commands  should  be  in  the  language. 

C)  Storage  commands 

These  include  storage  or  retrieval  of  programs  or  data,  defined  input  of 
data  blocks  or  text  or  calls  for  the  next  segment  of  code. 

Most  of  these  commands  should  also  be  usable  in  immediate  mode  and  as 
statements  within  a program. 

3.  Dartmouth  BASIC 
3.1  Why  BASIC? 


Most  of  the  user-oriented  and  problem-oriented  languages  were  designed  for 
the  special  use  of  certain  groups  of  experts.  Hence,  most  of  these 
languages  are  somewhat  difficult  to  learn  and  to  apply.  Recognizing  this 
problem  it  was  decided  that  a simple  language  was  needed.  It  must  have  very 
simple  grammatical  rules  and  must  be  capable  of  being  learned  in  a very 
short  time.  Thus  Dartmouth  BASIC  came  into  being.  It  is  easy  to  learn  and 
can  be  applied  to  most  computing  problems  quickly  and  easily. 
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BASIC  also  does  have  the  capability  to  be  used  in  interactive  programs, 
that  is,  programs  that  require  or  allow  user's  participation  in  order  to 
achieve  the  desired  results.  Because  of  these  features  BASIC  has  become  a 
de  facto  standard  on  most  minicomputer  systems.  This  is  still  true  though 
it  has  some  shortcomings  and  therefore  should  not  be  used  where  these 
shortcomings  cause  serious  restrictions. 

Appendix  I shows  the  Dartmouth  BASIC  syntax. 

3.2  Limitations  of  the  BASIC  languages 


Since  the  time  BASIC  was  designed  several  changes  in  programming  philosophy 
have  taken  place.  The  modern  approach  is  to  write  GOTO-less  well  structured 
programs.  In  order  to  understand  a program  dynamically  it  is  important  to 
minimise  the  number  of  possible  execution  paths.  Shortcomings  and  conse- 
quences : 

a)  BASIC  has  no  COMPOUND  statement.  This  results  in  additional  GOTO's  and 
makes  the  program  opaque. 

b)  The  CONDITIONAL  statement  is  primitive  by  only  allowing  a line  number 
behind  the  'THEN'.  This  again  increases  the  number  of  execution  paths. 

c)  BASIC  does  not  provide  a general  subroutine  mechanism.  The  only 
characteristics  of  a subroutine  in  BASIC  is  the  RETURN  to  the  line 
after  the  calling  line  by  the  RETURN  statement.  In  general  it  is  not 
possible  to  indicate  the  body  of  a subroutine.  It  is  possible  to 
scatter  a subroutine  over  the  program.  (Certainly  not  recommended.) 

d)  BASIC  is  not  appropriate  for  writing  symbolic  programs  because 
symbolic  labels  are  not  allowed.  This  fact  also  causes  difficulties 
for  rearranging  a program. 

e)  BASIC  does  not  use  the  concept  of  local  variables.  All  variables  are 
global  and  restricted  to  one  or  two  characters  thus  making  it 
difficult  to  write  long  programs. 

f)  The  limitation  of  data  types  to  real  and  string  restricts  the  possibi- 
lities of  defining  other  data  structures. 


All  these  items  may  restrict  the  use  of  RT-BASIC  for  programming  complex 
real-time  systems.  Problems  where  disadvantages  caused  by  these  limitations 
can't  be  avoided  should  not  be  programmed  in  BASIC.  These  are  not  inherent 
limitations  of  BASIC  systems.  Some  of  these  limitations  have  been  overcome 
by  certain  implementations. 

On  the  other  hand  especially  because  it  lacks  declarations  and  has  few  data 
types  etc.  BASIC  is  easy  to  use  when  problems  can  be  overviewed  by  a single 
person  and  the  programs  are  reasonably  small. 


4.  Functional  Needs  for  Real-time  Enhancements  to  Dartmouth  BASIC 


4.1.  Introduction 

The  BASIC  features  which  have  made  the  language  successful  in  different 
application  areas  also  apply  for  a class  of  real-time  applications.  A great 
number  of  implementations  already  exist  that  use  various  extensions  to  meet 
real-time  needs.  This  document  is  an  attempt  to  define  the  common  require- 
ments of  the  real-time  user  and  maintains  the  spirit  of  BASIC  by  using  key 
words  instead  of  parameterized  calls. 


The  following  diagram  is  an  illustration  of  a possible  real-time  system: 
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Syntax  examples  used  in  this  document  are  only  for  illustration  and  are  not 
part  of  the  proposal. 


4.2.  Process  Input-Output 


Process  input-output  functional  interfaces  allow  access  to  specified  analog 
and  digital  inputs  and  outputs.  All  the  process  input-output  operations  are 
executed  in  direct  response  to  the  occurrence  in  the  program.  (This 
classification  is  chosen  because  many  comparison  candidates  use  it.) 

4.2.1.  Analog  input-output 

The  parameters  needed  for  these  operations  are  specifications  of: 

a)  The  hardware  channel (s) 

b)  Access  Mode  (random,  sequential,  etc.) 

c)  Hardware-software  conversion 

d)  Error  information 

The  data  transferred  over  the  analog  input-output  interface  will  be  repre- 
sented in  standard  floating  point  form. 

4.2.2.  Digital  (discrete)  input-output 

The  parameters  needed  for  these  operations  are  specifications  of: 

a)  Digital  I/O  point  or  series  of  points 
(discrete  I/O  channels) 

b)  Hardware- software  conversion  information 

c)  Error  identification  information. 

The  data  transferred  may  be  to  or  from  a standard  floating  point  variable 
or  a bit  string  variable  (see  Section  6). 

4.2.3.  Pulse  (train)  input-output 

The  parameters  required  for  these  operations  are  specifications  of: 

a)  Channel (s) 

b)  Hardware-software  conversion  information 

c)  Error  identification  information. 
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4.3.  Access  to  System  Time  and  Date 

The  current  time  must  be  available  to  real-time  BASIC  programs  for  use  in 
calculations  and  logging.  It  must  give  date  (year,  month,  day)  and  time 
information  (hour,  minute,  seconds). 

4.4.  Extension  of  conventional  I/O  (terminals) 

Process  Control  configurations  are  usually  not  limited  to  a single  system 
console.  System  configuration  often  includes  teletypes,  line  printers  and 
CRT's.  An  example  is  the  need  to  print  test  results  on  terminal  printers 
local  to  the  tests  being  performed.  There  is  therefore  a need  to  extend  the 
PRINT  and  INPUT  statements  to  include  the  specification  of  the  target 
devices.  Operator  and  device  errors  in  response  to  INPUT  statements 
shouldn't  be  fatal . 

4.5.  Extension  of  statements  controlling  program  flow 

Dartmouth  BASIC  includes  control  statements  that  allow  the  interruption  of 
the  normal  sequence  of  execution  of  statements  by  causing  execution  of  a 
specified  program  or  program  part  rather  than  the  next  higher  line  number. 
There  are  two  approaches  for  incorporation  of  this  feature.  For  simple 
systems  it  can  be  handled  on  the  interrupt  level  by  a statement  that 
connects  an  Interrupt  to  a line  number  or  subroutine  (case  a). 

The  other  approach  is  to  use  BASIC  as  a software  layer  on  top  of  a real- 
time process-control  system.  Recent  implementations  more  often  use  the 
second  approach  (case  b). 

a)  Real-time  BASIC  requires  extension  of  these  control  statements  to  allow 
the  execution  of  specified  subroutines  upon  the  occurence  of  real  time 
events  related  to  the  system  time  "AFTER  10  seconds"  "EVERY  100  minutes"  or 
to  the  occurence  of  interrupts  or  special  input  commands. 
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All  these  events  have  to  be  connected  with  their  related  subroutines  before 
their  occurrence  at  run  time.  In  such  a simple  system  the  introduction  of 
different  interrupt  subroutine  levels  should  be  avoided. 


Example: 


10  ON  INT  5 GOSUB  1000 
1000  REM  "START  OF  SERVICE  ROUTINE" 


RETURN 

30  AFTER  T1  GOSUB  2000 
2000  REM  "START  OF  SERVICE  ROUTINE" 


RETURN 

d)  If  BASIC  is  hooked  onto  a real  time  executive  it  clearly  has  to  use  the 
tasking  mechanism  of  the  underlying  system.  The  programmer  should  only  be 
faced  with  events  and  tasks.  This  also  overcomes  one  of  the  BASIC  restric- 
tions namely  having  all  variables  global.  Each  task  has  its  own  line 
numbers  and  variable  names  only  the  task  names  and  event  names  are  global. 

When  writing  a task  the  user  types  the  task  name  and  specifies  the  task 
level.  The  level  of  a task  defines  which  tasks  are  allowed  to  interrupt  it. 

The  synchronisation  of  tasks  can  be  done  by  two  operations  on  events 
namely. 


WAIT  event  |",event...J  and  SIGNAL  event 
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WAIT  suspends  the  task  until  one  of  the  events  occurs.  An  "ACTIVATE  task 
name"  can  activate  other  tasks.  Deactivation  must  be  done  by  the  task 
itself. 

example:  TASK  BASE  LEVEL  0 

10  REM  BEGINNING  OF  TASK  "BASE"  LEVEL  0 


100  ON  HALLO  ACTIVATE  GET 

\ 

eventname 

200  END 

TASK  GET  LEVEL  1 

10  REM  HERE  STARTS  TASK  "GET"  LEVEL  1 


100  END 

example  of  synchronisation 

TASK  BASE  LEVEL  0 
10  REM  BEGIN 


50  WAIT  TICK 

60  REM  "TICK"  IS  A DECLARED  EVENT 


100  END 

TASK  PUT  LEVEL  1 
10  REM  BEGIN 


20 


SIGNAL  TICK 
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For  the  transfer  of  data  between  tasks  two  commands  are  foreseen 

SEND  dataname  VIA  eventname  TO  taskname 
and  RECEIVE  dataname  FROM  taskname. 

TASK  2 
20  WAIT  YOU 

30  RECEIVE  B(2)  FROM  TASK  1 

By  this  mechanism  the  element  A(3)  of  task  1 is  sent  to  B(2)  of  task  2 
using  event  "YOU"  as  the  synchronising  element.  (Additions  for  access  to 
remote  files  see  9.) 

Time  events  are  often  used  and  therefore  should  be  treated  in  a different 
way.  A minimum  set  is:  "200  AFTER  time  interval  ACTIVATE  taskname"  but 
also  "AT  time"  would  be  desirable.  EVERY  causes  some  problems  and  therefore 
should  be  avoided. 

For  the  treatment  of  events  a "SET  eventname"  would  be  necessary.  "TEST 
event  name"  or  "CLEAR  eventname"  is  not  essential  (done  by  the  system). 

The  system  clearly  must  be  able  to  save  and  get  tasks  to  and  from  bulk 
storage,  list  and  delete  tasks. 

4.6.  Extensions  to  Data  Types  and  Operations 

The  number  of  data  types  in  real-time  BASIC  should  be  kept  to  a minimum. 

The  introduction  of  new  data  types  may  offer  advantages  (for  example  run 
time  efficiency).  In  the  proposed  "Minimal  BASIC",  two  data  types  exist. 

The  data  type  floating  point  variable  and  the  data  type  string.  The 
corresponding  data  structure  built  of  these  data  types  are  array  (1  or  2 
dimensional)  and  string  arrays. 


AnnonHi v TIT 


example: 

TASK  1 

100  SEND  A(3)  VIA  YOU  TO  TASK  2 


-114- 


Manipulation  of  analog  and  digital  I/O  data  can  be  done  using  the  standard 
floating  point  representation.  Appropriate  conversion  routines  in  analog 
and  digital  I/O  statements  will  convert  discrete  (digital)  inputs-outputs 
into  the  internal  machine  representation.  In  this  form,  no  integer 
representation  will  be  required.  However,  a bit  pattern  data  structure  is 
strongly  desirable,  especially  in  applications  like  automatic  digital 
testing  where  a large  number  of  bits  in  the  order  of  hundreds,  are 
required.  It  must  also  be  possible  to  write,  input  and  print  a represen- 
tation of  bit  pattern  e.g.  in  octal,  hexadecimal  or  binary.  In  summary,  the 
following  process  data  have  to  have  internal  representation  in  the  BASIC 
system: 

1.  Analog  input-output  - Values  can  be  represented  by  standard  floating 
point  variable. 

2.  Digital  input/output  - The  bit  pattern  of  physical  "0"  or  "1"  combi- 
nation can  be  represented  by  a string  of  "0"  or  "1"  in  a bit  string  or 
by  an  equivalent  floating  point  representation,  (i.e.  right  justified) 

Additional  operations  are  required  to  manipulate  internal  representation  of 
external  discrete  process  data.  The  Boolean  operators  needed  are: 

AND,  OR,  NOT,  Exclusive  OR,  SHIFT,  BIT  TEST/SET/CLEAR 
Preferrably  functions  should  be  avoided. 

4.7.  External  Subroutines 


Calls  to  user-generated  non  BASIC  subroutines  that  are  external  to  the 
BASIC  system  should  be  provided. 
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4.8.  Extension  to  Error  Handling 

A very  important  consideration  in  the  use  of  real-time  BASIC  in  industrial 
applications  is  the  type  of  error  handling  capability  that  should  be  pro- 
vided in  the  language. 

Whenever  errors  occur  during  BASIC  program  execution  (such  as  overflow, 
incorrect  data  input,  I/O  errors,  etc),  they  should  result  in  the  setting 
of  an  error  flag  using  a system  variable.  Such  an  error  flag  may  be  tested 
by  an  extension  of  the  control  statement  of  the  form: 

5 ON  ERROR  GOTO  (GOSUB)  100 

A scheme  should  be  provided  to  allow  the  user  to  identify  the  error  cause. 

4.9.  File  Handling  and  Interprocessor  Communication 

There  are  strong  requirements  for  file  handling  in  measurement  and  control 
applications.  It  is  important  that  the  standard  syntax  for  file  manipu- 
lation could  be  extended  to  access  files  that  may  be  resident  on  the  mass 
storage  of  a remote  computer  in  a distributed  system  network.  The  same 
remarks  apply  to  segmenting,  where  program  chains  or  tasks  may  be  resident 
in  the  same  computer  mass  storage  device  or  in  another  computer  in  a 
distributed  system  network. 


Summary  of  BASIC  Statements  Appendix  I 


Purpose 

Example 

1. 

Elementary  BASIC 

INPUT 

Reads  data  from  teletype 

17 

INPUT  A$,  X 

READ 

Reads  data  from  data  b.'ock 

17 

READ  X,  Yl.  M(J  » 2.  31,  N$ 

DATA 

Storage  area  for  data 

17 

DATA  - l,  2.07,  31416E  - 4,  127829,  JONES 

PRINT 

Types  numbers  and  labels 

17 

PRINT  "ANSWER  X.  A * 8,  N$ 

LET 

Computes  and  assigns  value 

17 

LET  X2  - X ♦ Y 1 2 

GO  TO 

Transfers  control 

17 

GO  TO  175 

IF 

Conditional  transfer 

17 

IF  Til,  J)  < - 25  THEN  175 

FOR 

Sets  up  and  operates  a loop 

17 

FOR  N - 10  TO  1 STEP  - 1 

NEXT 

Closes  loop 

17 

NEXT  N 

END 

Final  statement  in  program 

17 

END 

2. 

Advanced  BASIC 

INPUT 

Reads  data  from  the  teletype 

17 

INPUT  X,  Y4,  Z 

LINPUT 

Inputs  an  entire  line  as  a single  string 

17 

LINPUT  A$ 

OEF 

Defines  a function 

17 

DEF  FNG  (X)  - 2 • SIN  (XI  4 EXP  (-  X) 

FNEND 

End  of  a multiple-line  OEF 

17 

FNEND 

G0SU8 

Transfers  to  a subroutine 

17 

GOSUB  800 

RETURN 

Returns  to  statement  following  GOSUB 

17 

RETURN 

RESTORE 

Restores  data  to  beginning 

17 

RESTORE 

REM 

Permits  comments 

17 

REM  BEGINNING  OF  SUBROUTINE 

DIM 

Declares  dimensions  of  lists  and  tables 

• 17 

DIM  A ( 1 2> , B(3,  5) 

STOP 

Stops  program 

17 

STOP 

CHANGE 

Convert  string  of  characters  to  a vector, 

17 

CHANGE  AS  TO  V 

vice  vensa 

ON 

Multiple  way  branch 

17 

ON  X*Z  GO  TO  200,  400,  750 

RANDOMIZE 

"Randomize"  the  random  number 

17 

RANDOMIZE 

generator 

3. 

File  instructions 

FILES 

Specified  files 

17 

FILES  DATA,  4 

FILE 

Names  or  renames  a file 

17 

FILE  #2:  NS 

INPUT 

Reads  from  a teletype  file 

17 

INPUT  #1:  X,  AS,  Y 

PRINT 

"Prints"  to  a teletype  file 

17 

PRINT  #1 : A,  B,  C 

READ 

Reads  from  a random  file 

17 

READ  #2:  X,  Y(1),  Y(2I 

WRITE 

Writes  to  a random  file 

17 

WRITE  #2:  R,  S+T 

RESET 

Set  random  file  pointer 

17 

RESET  #2.  LOCI2I  - 1 

SCRATCH 

Scratch  a file 

17 

SCRATCH  #3 

4. 

Matrix  instructions  I 

MAT  INPUT 

Reads  data,  any  number,  from  teletype 

17 

MAT  INPUT  V 

MAT  READ 

Reads  a matrix  from  the  data  block 

17 

MAT  READ  Z(M,  Nl 

MAT  PRINT 

Types  a vector  or  matrix 

17 

MAT  PRINT  A 

MAT  + 

Matrix  addition 

17 

MAT  C - A + B 

MAT  - 

Matrix  subtraction 

17 

MAT  C = A - B 

MAT  * 

Matrix  multiplication 

17 

MAT  C « A 4 B 

MAT  ( ) * 

Scalar  multiplication 

• "1 

MAT  C = (COS  (XI)  4 A 

MAT  INV 

Matrix  inverse  1 

17 

MAT  C - INV  (A) 

MAT  TRN 

Matrix  transpose 

17 

NAT  C - TRN  (A) 

MAT  ZER 

Matrix  of  all  zeroes 

17 

M/\T  C * ZE  R 

MAT  CON 

Matrix  of  all  ones 

17 

MAT  C - CON  (15) 

MAT  IDN 

Identity  matrix 

17 

MAT  C » IDN 

5. 

Notes 

Variables 

X,  Y7,  A,  A(XI,  B(A(X),  51,  A$,  07$,  N$(l),  T$(A,B) 

Operations 

♦ , *,  /.  t 

Relations 

<,  <».•,>.>•,<> 

Functions 

SDR,  SIN,  COS,  TAN,  ATN,  LOG,  EXP.  ABS, 

SGN,  INT, 

RND,  ASC,  LOC,  LOF,  NUM.  TAB 

Appendix  II 


Nine  candidates  were  chosen.  It  is  clear  that  this  is  not  a complete 
set  and  that  other  candidates  should  be  also  taken  into  account. 

List  of  candidates: 


ADAPTS  (Varian  Extended  BASIC)  / 1/ 
BASEX  (Phys.  Inst.  Univ.  Freiburg)  /2/ 
BASIC/RT  11  (DEC)  /3/ 
FPL  (F0XB0R0)  /4/ 
INDUSTRIAL  BASIC  (DEC)  /5/ 
PROCESS  BASIC  (Unicomp)  /6/ 
RTE-B  (HP)  (V 
KENT  K90  BASIC  18/ 
CASIC  B Schlumberger  /9/ 


Some  of  the  examples  may  be  erroneous  due  to  incomplete 
descriptions. 
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Criteria  for  comparison 

To  justify  the  name  real-time-BASIC  a language  should  be  a superset  of 
Dartmouth-BASIC  (or  in  the  future  of  "Minimal  BASIC"  (ANSI)). 

The  extensions  are  classified  in  the  following  way: 

1.  Extension  of  the  algorithmic  part 

1.1.  Mnemotechniques 

1.2.  Objects  and  operations 

1.2.1  Text  handling 

1.2.2  Logic  Operations 

1.2.3  Bit  Manipulation 

1.3.  Specification  of  peripherals 

1.4.  Format  specification 

1.5.  File  handling 

1.6.  Insertion  of  assembler  routines 

1.7.  Segmentation  of  user  programs 

2.  Process  I/O 

Objects  (Philosophy  of  treatment) 

2.1.  Analog  inputs 

2.1.1  Input  of  a single  value 

2.1.2  Input  of  moi  e than  one  value  without  channel  switching 

2.1.3  Input  of  a single  value  with  channel  switching 

2.1.4  Input  of  multiple  values  with  channel  switching 

2.2.  Analog  Outputs 

2.2.1  Output  of  a single  value 

2.2.2  Output  of  more  than  one  value  without  channel  switching 

2.2.3  Output  of  a single  value  with  channel  switching 

2.2.4  Output  of  multiple  values  with  channel  switching 

2.3.  Digital  Inputs 

2.3. 1 Single  Bits 

2.3.2  Words 


•T" 


\ 
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Diqital  Outputs 


2.4.1  Single  Bits 
2.4.3  Words 

Pulse  inputs 
Pulse  output 

Connection  of  other  peripherals 
External  Interrupts 

Connection  of  a program  segment  with  an  interrupt 
Disabling  and  enabling  of  interrupts 
Interrupt  levels  (Nested  Interrupts) 

Treatment  of  time 

Start  of  a program  segment  at  an  absolut  instant  of  time 
Start  of  a program  segment  after  a specified  time 
Repetition  of  a program  segment  after  a specified  time 

Parallel  execution  of  program  segments 

Synchronisation  of  program  segments 

Error  treatment 


* -ksm 
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1.1.  Mnemotechniques 
ADAPTS: 

like  Dartmouth-BASIC 
BASEX: 


Variable  names  use  1 to  4 alphanumeric  characters  starting  with 
a letter. 


BASIC  RT/11 : 

like  Dartmouth-BASIC 


FPL: 

Variable  names  start  with  a letter.  An  arbitrary  number  of 
alphanumeric  characters  can  be  used. 

INDUSTRIAL  BASIC: 

like  Dartmouth-BASIC 

PROCESS  BASIC: 

Variables  and  labels  use  the  first  6 alphanumeric  characters  of 
an  alphanumeric  sequence  starting  with  a letter. 

RTE-B: 

like  Dartmouth-BASIC 


1.2.  Objects  and  Operations  on  these  objects 


used  datatypes: 

ADAPTS: 

BASEX: 

BASIC  RT/11: 
FPL: 


real 

real,  string 
real,  string 
real 


-122- 


< 

4 


i 


INDUSTRIAL  BASIC:  real,  string 

PROCESS  BASIC:  real,  3 times  integer  (variable  length) 

RTE-B:  real 

1.2.1  Text  handling 

ADAPTS:  no 

BASEX: 

Text  handling  uses  string  variables  and  ASCII-  and  Hexa  decimal  constants. 
Storage  for  string  variables  (var.  name  ?)  is  reserved  by  the  CHAR- 
statement,  i.e.  1 CHAR  AX?  (27). 

The  stored  characters  can  be  addressed  by  AX?  (N)  (single  character 
adressing),  by  AX?  all  of  them  or  by  AX?  (N,  M)  a substring. 

Operations  for  the  string  variables  are: 

NOT?  Inversion  per  bit 

AND?  AND  per  bit 

OR?  OR  per  bit 

& Concatenation 

In  addition  to  that  all  comparison  operations  can  be  applied. 

BASIC  RT/11: 

String  variables  and  ASCII  constants  similar  to  Dartmouth  BASIC  are 
used.  Comparison  and  concatenation  are  available.  In  addition  there 
are  system  functions  for  string  variaoles  and  constants. 

FPL:  no 

INDUSTRIAL  BASIC: 

like  BASIC  RT/.l 

PROCESS  BASIC:  no 


\ 


RTE-B: 


no 
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1.2.2  Logic  Operations 


ADAPTS: 


AND,  OR,  NOT  are  used.  Real  values  express  the  values  of  the  logical 
variables 

(0  = false,  / 0 = true) 


BASEX: 


like  ADAPTS 


BASIC  RT/11: 
no 


FPL: 


no 


INDUSTRIAL  BASIC: 


no 


PROCESS  BASIC: 


no 


RTE-8: 


like  ADAPTS 


1.2.3  Bit  manipulation 


ADAPTS:  no 


BASEX: 


is  handled  by  string  variables  (see  1.2.1).  The  system  function 
CHG  is  used  for  conversion  between  numerical-  and  string  variables. 
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BASIC  RT/11: 

is  handled  by  string  variables.  System  functions  for  conversion  and 
special  tasks  are  available. 


FPL: 

no 


INDUSTRIAL  BASIC: 

like  BASIC  RT/11 

PROCESS  BASIC: 

Assembler  level  and  some  Macro  instructions  allow  bit  manipulation  on 
all  data  types. 


RTE-B: 

Bit  manipulation  is  done  by  system  subroutines  on  "reals'1. 


the  following  subroutines  are  used: 


I OR 

oring 

I NOT 

inversion  | 

1E0R 

exclusive  or 

IAND 

anding 

ISHIFT 

shift 

IBSET 

set  a bit 

IBCLR 

clear  a bit 

IBTST 

test  a bit 

Speci fi cation 

of  peripheral 

ADAPTS: 

no 

8ASEX: 

By  DEV  (number  of  u ■ ,n  -•  can  be  activated  with  INPUT  and 

PRINT.  By  DEV (01  the  system  terminal  is  activates 
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BASIC  RT/11: 

INPUT  -#  n:  and  PRINT ./Fn  is  used  to  activate  I/O  peripherals  and 
bulk  storage,  n is  the  logical  unit  number. 


FPL: 

PRINT  (n)and  INPUT  / n) (n  = unit  number)  are  used  to  activate  I/O 
units. 

INDUSTRIAL  BASIC: 

like  BASIC  RT/11 

PROCESS  BASIC: 

The  Macros  DEG,  DAG  can  be  used  to  define  I/O  units.  Those  can  be 
activated  by  ISC,  OSC,  Ein,  Aus  macros. 

INPUT  n and  PRINT  n (n  = unit  number)  can  also  be  used. 

ISC,  OSC:  I/O  of  one  character 

EIN,  AUS:  I/O  of  an  arbitrary  amount  of  information 


RTE-B : 

PRINT /^n  and  INPUT /^n  (n  = unit  number)  activate  additional  I/O  units. 


1.4.  Format  specifications 
ADAPTS: 

The  system  function  TAB(n)  is  used  to  set  the  typewriter  into  n-th 
position  (only  with  PRINT  statements) 

BASEX: 

Also  TAB(n)  and  format  specification  FMT.  The  specifications  are: 

A automatic  format 

F (n.m)  floating  point  without  exponent 
E (n.m)  floating  point  with  exponent 

n and  m define  total  number  of  characters  and  number  of  digits  after 
point. 
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BASIC  RT/11: 

TAB(n)  only  with  PRINT 

FPL: 

no 

INDUSTRIAL  BASIC: 

like  BASIC  RT/11 

PROCESS  BASIC: 

The  AUS  macro  can  be  modified  by 


GLE 

floating  point  with  exponent 

GLF 

I t 

floating  point 

ITG 

integer 

ZTB 

line  feed  and  TAB 

ZTI 

line  feed  and  TAB  for  address  list  element 

HEX 

Hexadecimal  information 

VTX 

variable  text 

TEX 

fixed  text 

NFZ 

n-times  same  character 

FVI 

pointer  to  format  list  (indirect) 

FEN 

pointer  to  format  list  or  END 

i 


RTE-B:  no 

1.5.  File  handling 
ADAPTS: 

Background  storage  uses  magnetic  Tape.  Statements  are 

OPEN  Open  file 

CLOSE  close  file 

PUT  write  into  file 

GET  read  from  file 

FLIST  list  all  files 


t 
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DELETE  delete  files 

SAVE  write  core  buffer  into  file 

CLEAR  clear  all  files 

ASSIGN  load  core  buffer  from  file 

BASEX: 

There  are  subroutines  (activated  by  CALL) 

CREA  open  file 

KILL  delete  file 

ALTR  change  name 

LENG  change  length 

PROT  define  read/write  protection 

OPEN  open  file  and  assign  logical  number 

CLSE  close  file 

GFB,  GFBS  read  block  into  numerical  or  string  field 

PFB,  PFBS  write  block  into  numerical  or  string  filed 


BASIC  RT/11: 

Two  types  of  files  are  defined: 

a)  ASCII-sequential  file 

b)  virtual-memory  file 

a)  is  used  to  store  ASCII  characters  for  buffered  I/O  and 
program  sequencing  (see  1.7) 

b)  is  a data  background  storage  for  data  fields  and  single  elements 
can  be  accessed,  read  or  written. 

Statements: 

OPEN  open  and  specify  a file 

CLOSE  close  a file 

PRINT, INPUT  (see  1.3) 
blulk  storage  is  tape  and/or  disc. 


FPL: 


no 


INDUSTRIAL  BASIC: 

Sequential  files  to  store  numerical  and  string  data. 

Statements 

PRINT  write 

INPUT  read 

RESTORE  positioning 

CLOSE  close  file 

IF  END  ...  THEN  End  of  file  check 


PROCESS  BASIC: 

Backoround  storage  can  be  used  like  other  I/O  units  and  can  be 
accessed  via  AUS,  EIN  macros  (formatted,  unformatted,  buffered, 
unbuffered,  sequential,  random  with  or  without  conversion). 

RTE-B: 

Magtape  can  be  accessed  by  the  following  subroutines: 

MTTRD  read 

MTTRT  wri te 

MTTPT  positioning 

MTTFS  controlling 

The  subroutines  are  activated  with  CALL. 

1.6  Insertion  of  assembly  routines: 

ADAPTS: 

Assembly  routines  can  be  inserted  at  system  generation  time.  These 
subroutines  are  activated  bv  CALL'S. 

BASEX: 

At  system  generation  time  a)  and  b)  can  be  loaded. 

a)  Assembly  routines.  These  are  called  by  CALL  with  0-4  parameters 
(numerical  or  string) 

b)  System  process  variables  (see  2.) 

These  are  accessed  directly  or  via  the  PUT-statement  (see  2.) 

It  is  possible  to  pass  one  numerical  parameter. 
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BASIC  RT/11: 

like  ADAPTS.  Number  of  parameters  only  restricted  by  line  length. 


FPL: 

Assembler  routines  must  be  installed  when  the  system  is  delivered 
and  can't  be  loaded  later.  (CALL) 

INDUSTRIAL  BASIC: 

Assembler  routines  can  be  loaded  at  system  generation  time.  They 
have  to  be  declared  by  UDEF  ...  and  then  can  be  called  like  any 
other.  System  function  (sometimes  with  dummy  variables)  (no  CALL). 
4 numerical  and  2 string  parameters  can  be  passed. 

PROCESS  BASIC: 

The  assembler  level  and  the  macro  assembler  level  and  two  of  the 
three  levels  in  the  program.  The  levels  can  mixed. 


RTE-B: 

Installation  and  call  like  ADAPTS. 

1.7  Segmentation  of  user  programs 

ADAPTS: 

no 

BASEX: 

It  is  distinguished  between  ROOT-programs  and  segments.  A single  level 
tree  structure  is  used.  A segment  can  only  be  called  in  the  root.  The 
programs  roots  and  segments  are  translated  separately  and  are  then 
combined  into  a package.  Only  the  root  program  is  coreresident  with 
one  segment  at  a time.  All  segments  use  the  same  overlay  area. 
Variables  in  segments  which  are  not  used  in  the  root  are  local.  All 
variables  in  the  root  are  global.  Data  can  be  passed  via  global 
variables  and  files. 
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Statements: 

LINK  name  call  of  segment  (only  by  root) 

END  SEGMENT  End  of  segment  (only  in  segment) 

BASIC  RT/11: 

The  OVERLAY  statement  provides  a means  for  inserting  parts  of 
programs  into  a running  program  (from  ASCII-sequential  files) 

(see  1.5.) 

' «3 

Long  programs  can  be  divided  by  the  CHAIN-statement.  Whenever  a CHAIN 
is  reached  the  core  buffer  is  cleared  and  the  next  program  part  is 
loaded.  The  data  transfer  Between  the  CHAIN-parts  is  only  possible 
via  files. 


FPL: 

no 

INDUSTRIAL  BASIC: 

CHAIN  exists. 

PROCESS  BASIC: 

Global  (COMMON)  and  local  (DIMENSION)  naming  is  possible. 

Different  programs  (in  core  or  on  background  storage)  can  be  linked. 

RTE-B: 

no 

2.  Process  - I/O 

Elements  which  are  used  for  Process  I/O  are  called  process  objects. 
Generally  nearly  all  objects  are  assembler  programs  which  specify 
addresses  and  procedures  by  names  or  parameters.  There  ar-  implementations 
with  one  name  for  several  process  conncections  and  others  where  several 
subroutines  specify  different  functions  of  one  process  connection. 
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INDUSTRIAL  BASIC  as  an  exception  and  does  not  use  assembler  programs  for 
this  purpose. 

Some  different  program  systems  use  different  process  objects.  These 
are  explained  below. 

ADAPTS: 

Process  objects  are  assembler  subroutines  with  invariant  functions. 

Their  process  addresses  are  defined  by  parameters.  For  example: 
input  of  process  data  uses  two  subroutines: 

a)  Transfer  of  data  from  process  input  to  internal  data  field. 

b)  Transfer  of  data  from  process  input  to  background  storage. 

There  is  no  distrinction  between  analog  and  digital  input.  The 
user  has  to  specify  the  process  address  by  "channel"  and  "frame". 

In  the  following  example  / 1 is  an  analog  and  /2a  digital  input. 

When  calling  the  subroutine  DATAI  (see  2.1.1)  the  statements  look 
like: 

#1  100  CALL  DATAI  (0,A(1), 10,1,0) 

#2  100  CALL  DATAI  (0,A(1),  10,2,0) 

(frame  is  underlined,  channel  = 0) 

A similar  subroutine  is  used  for  process  outputs.  Two  special 
subroutines  are  used  to  treat  pulse-  and  status  word  output. 

The  specified  1/0  subroutines  are  able  to  increment  the  internal 
addresses  up  to  a specified  value. 

BASEX: 

Process  objects  are  assembler  subroutines  and  a new  type  of  variable 
- the  process  variable.  This  variable  can  be  defined  by  the  user 
(using  EQUI,  EQU0  see  2.7.)  or  is  defined  for  standard  peripherals. 

Process  variables  are  syntactically  treated  like  normal  variables  (except 
only  one  index).  The  index  can'be  used  to  pass  channel  specification. 

As  far  as  semantics  is  concerned  the  process  variables  are  connected 
with  the  environment  whereas  the  other  varibles  are  related  to  the 
computer  system. 
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It  is  distinguished  between  input  and  output  variables.  Input 
variables  can  be  used  everywhere  in  numerical  expressions  except 
on  the  left  side  of  an  assignment  whereas  output  variables  are  only 
on  the  left  side  of  an  assignment.  To  treat  process  output 
variables  which  generate  invariant  signals  one  can  use  the  PUT 
statement. 

The  following  example  shows  3 process  variables 

a)  input  from  process 

b)  value  calculated  by  program 

c)  output  of  constant  value. 

1 EQUI  INPU (X)=%. . . % 101  PRINT  NORM-INPU(K) 

2 EQUO  0UTP(X)=%. . .%  102  LET  0UTP(I+5)=A(K)+EXP(Y) 

3 EQUO  PULS=%. . .%  103  PUT  PULS 


definition 


run  time  call 


. ..  represents  machine  code 


BASIC  RT/11: 

Process  objects  are  assembler  programs.  There  are  several  subrJLlt' nes 
with  different  procedures  for  one  process  peripheral.  Some  of  the 
procedures  are  specified  by  parameters.  5 "modules"  (module  = sub- 
routine package  for  one  process  peripheral)  exist. 

1.  Buffer  and  field  treatment 

2.  Analog  to  digital  conversion 

3.  Real  time  clock 

4.  Digital  output 

5.  Display 

Tne  example  shows  an  analog  data  input  where  the  "ADC"  subroutine 
package  transfers  one  value  and  "RTS"  50  values  into  a buffer. 

One  parameter  in  "RTS"  (underlined)  defines  the  input  strobe 
sequence. 

100  CALL  "ADC"  (1,A) 

100  CALL  "RTS"  (A, 0,4, 50,0) 

(see  2.1.) 


FPL: 
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The  process  object  is  a process  variable  to  be  defined  in  a DEF-command 
(see  2.1.1)  and  can  be  activated  or  deactivated  by  the  program. 

All  the  specifications  of  addresses  and  procedures  are  defined  by 
that  DEF-command.  The  name  of  the  proces ; variable  can  be  used  in 
numerical  expressions  (with  certain  restrictions).  If  the  "Task" 
corresponding  to  the  process  variable  is  activated  it  transfers  data 
from  or  to  the  process. 

The  example  shows  the  definition  of  an  analog  input  and  the  transfer 
of  a value  into  the  mainprogram. 

DEF:  AIN:  ANALOG: 

...  specifications  like 

channelnumber 

transferperiod 

conversiontype 

1 imits 

PID-control 

etc. 

mainprogram:  ACT:  ANALOG; 

LET:  A= ANALOG/4; 

DEACT:  ANALOG; 

INDUSTRIAL  BASIC: 

Process  objects  are  assembler  functions  which  either  be  defined  by  the 
user  (then  they  must  be  inserted  into  the  system  and  declared  by  UDEF 
(see  2.7.))  or  system  functions  for  standard  peripherals.  Syntactically 
these  functions  are  treated  like  the  others,  i.e.  EXP,  SQR  etc.  but 
they  are  not  allowed  to  be  used  on  the  left  side  of  an  assignment. 

This  causes  use  of  dummy  variables  on  the  left  side.  The  data  transfer 
and  other  specifications  are  done  by  parameters. 

Analog  input  LET  A=ANI(0,10) 

Digital  output  LET  D=SD0 (1,1,0) 

(D  = dummy,  see  2.1.,  2.4.) 
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PROCESS  BASIC: 

Process  objects  are  macros  defined  by  DEG,  DAG. 

(which  means:  Define  Input  Device,  Define  Output  Device) 

RTE-B: 

A philosophy  similar  to  BASIC  RT/11  is  used.  Process  objects  are 
assembler  routines  which  name  a process  connection  and  a procedure. 

The  parameters  are  used  to  specify  the  channel  and  transfer  of 
measurement  and  control  data. 

The  example  shows  analog  input  with  sequential  and  random  channel 
switching. 

a)  100  CALL  AISQV  (5,1,A(K),E) 

b)  100  CALL  AIRDV  (5,C(1),A(K),E) 

2.1.  Analog-Input 

2.1.1.  Input  of  a value 
ADAPTS: 

use  of  general  input  routine 

DATAI  (channel,  field  element,  number,  frame,  period) 

A floating  point  number  is  stored  in  the  field. 

10  CALL  DATAI  (0,A(1) ,1,0,0) 

Another  possibility  is  to  use  the  subroutine  DATIF  with  the  same 
parameters  as  DATAI,  but  an  integer  value  is  stored  into  file  ^n 
(second  parameter) 

BASEX: 

The  process  variable  INA  (channel)  allows  access  to  ADC 
10  LET  A=INA(0) 


k 


■T 


^ f-  * *"•  . 9- 


9 


\ 
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BASIC  RT/11: 

The  system  subroutine  "ADC"  (channel,  variable)  is  used 
10  CALL  "ADC"  (0 , A) 

Another  possibility  is  to  use  the  system  subroutine  “RTS"  which  controls 
the  analog  input  timing. 

FPL: 

The  peripheral  has  to  be  defined. 

DEF:  AIN:  INA;  definition  of  name  ( INA) 

I RG : -10,10;  measurement  range 

ERG:  0,1000:GPM;  definition  of  used  unit 

In  the  program  this  input  can  be  activated  or  deactivated 
ACT:  INA 

LET:  A=INA 
DEACT:  INA; 

A variety  of  specifications  concerning  data  conversion,  limits  etc. 
is  possible. 

INDUSTRIAL  BASIC: 

The  system  function  ANI  (channel,  amplification)  is  responsible  for 
the  transfer. 

10  LET  A=ANI  (0,100) 

PROCESS  BASIC: 

Definition  of  the  peripheral  by  the  macro  DEG,  then  data  are  acquired 
by  INP. 

Definition: 

DEG  n,  program  address 
(n  = input  device  number) 

Assignment  of  a value: 

INPUT  u A 


4 
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RTE-B: 

Use  of  system  subroutine  for  sequential  access 

AISQV  (number  of  channels,  first  channel,  field,  error  parameter) 

10  CALL  AISQV  (1.0.A.E) 

Another  possibility  is  to  use  the  system  subroutine  for  random 
access.  AIRDV  (number  of  channels,  reference  field,  field,  error 
parameter).  The  reference  field  holds  the  channel  numbers  which 
have  to  be  used  sequentially. 


2.1.2  I nput  of  severa 1 data  values  without  channel  switching 
Parameter  specifications  like  2.1.1 


ADAPTS: 

10  CALL  DATA I (0,A( I) , 1,0,0) 


BASEX: 

10  FOR  1=1  TO  100 
20  LET  A/I)  = .INA(0) 

30  NEXT  I 

3ASIC  RT/11: 

10  FOR  1=1  TO  100 
20  CALL  "ADC"  (0,A(I)) 
30  NEXT  I 


FPL: 

Definition  of  process  connection  as  in  2.1.1 
ACT:  INA; 

LET:  1=1; 

10  LET:  A ( I ) = INA ; 

LET:  1=1+1 

IF  (I  100)  GOTO:  10; 

(there  is  no  FOR  loop  in  this  implementation) 
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INDUSTRIAL  BASIC: 

If)  FOR  1=1  TO  100 
20  LET  A( I ) = AN I (0,100) 

30  NEXT  I 

PROCESS  BASIC: 

DEG  n program  address 

FOR  1=1  TO  100 
INPUT  n A(I) 

NEXT  1 

RTE-B: 

10  FOR  1=1  to  100 
20  CALL  AISQV(1,0,A(I),E) 

30  NEXT  I 


2.1.3  Input  of  a value  with  channel  switching 

In  this  example  5 values  should  be  read  from  consecutive  channels 
starting  with  1 and  stored  into  A(l)  to  A(5) 


ADAPTS: 

5 FOR  1=1  TO  5 

6 CALL  DATA I (I,A(I), 1,0,0) 

7 NEXT  I 


BASEX: 

5 FOR  1=1  TO  5 

6 LET  A ( I ) = INA ( I ) 

7 NEXT  I 


BASIC  RT/11: 

5 FOR  1=1  TO  5 

6 CALL  "ADC"  (I,A(I)) 

7 NEXT  I 
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FPL: 

Like  2.1.1,  but  ■five  definitions  DEF : AIN : INA;  are  necessary  and 
five  assignments  in  the  program  are  needed. 

INDUSTRIAL  BASIC: 

5 FOR  1=1  TO  5 

6 LET  A(I)=ANI(I,100) 

7 NEXT  I 

PROCESS  BASIC: 

DEG  1,  program  address 


DEG  5, 

FOR  I = 1 TO  5 
INPUT  I A(I) 

NEXT  I 

RTE-B: 

5 CALL  AISQ  V(8, 1,A(1) ,E) 

2.1.4  Input  of  multiple  values  with  channel  switching 

In  this  example  100  values  should  be  read  from  each  channel  of  1-5  and 
stored  into  a data  field. 


ADAPTS: 

1 FOR  I = 1 TO  5 

2 CALL  DATA  I (I,A(I,1),  100,0,0) 

3 NEXT  I 
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BASEX: 

1 FOR  1=1  TO  5 

2 FOR  J=1  TO  100 

3 LET  A ( 1 , J)=INA( I ) 

4 NEXT  J 

5 NEXT  I 
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PROCESS  BASIC: 

DEG  1,  program  address 


DEG  5, 

FOR  I = 1 TO  5 
FOR  J = 1 TO  100 
INPUT  I A ( I , J ) 
NEXT  J 
NEXT  I 


I . 


t 


i 


i 


RTE-B: 

1 FOR  1=1  TO  5 

2 FOR  0=1  TO  100 

3 CALL  AISQV  (1,I,A(I,J),E) 

4 NEXT  J 

5 NEXT  I 

2.2.  Analog  Output 
2.2.1  Output  of  a value 

ADAPTS: 

Output  procedure  DAT AO  syntactically  like  input  procedure  DATAI 
BASEX: 

Use  of  process  variable  OUTA  (channel) 

1 LET  OUTA  (0)=A 

BASIC  RT/il:  no 

FPL:  no 


INDUSTRIAL  BASIC: 

The  system  function  ANO  (channel,  value)  can  be  used.  On  the  left 
side  there  is  a dummy  D. 

1 LET  D = ANO  (0,  1023) 


/ 
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PROCESS  BASIC: 

see  digital  output  (2.4.2) 

RTE-B: 

The  system  subroutine  AO V (channel,  channel  sequence,  data  field, 
error  parameter)  in  connection  with  SGAIN  (channel,  amplification 
factor)  can  be  used. 

1 CALL  AOV  ( 1 , K ( 1 ) ,A(1) ,E) 

Another  possibility  is  DAC  (channel,  value) 

1 CALL  DAC  (1,10) 

2.2.2  Output  of  multiple  values  without  channel  switching 

see  2.2.1  and  analog  input 

i 

2.2.3  Output  of  single  value  with  channel  switching 
see  2.2.1  and  analog  input 

2.2.4  Output  of  multiple  values  with  channel  switching 

l | 

2.3.  Digital  Input 
2.3.1  Input  of  single  bits: 

ADAPTS: 


BASEX: 

There  exists  a process  variable  INB  (bit  number) 
1 LET  A= INB ( 0 ) 

BASIC  RT/11: 


no 
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FPL: 

Digital  input  module  is  specified  for  bitwise  input 
DEF:  DIN:  INPU;  naming 

CHAN:  0 

BITIN:  INB(l);  naming  of  the  single  bits. 

after  being  activated  the  program  can  access  the  single  bits. 

ACT:  INPU; 

LET:  A=INB(1) 

INDUSTRIAL  BASIC: 

The  system  functions  RDI  (basis-bit,  number  of  bits)  and  RDO  (basis- 
bit,  number  of  bits)  allow  the  input  of  single  external  bits  or 
the  input  of  the  last  digital  output  values  (RDO  read  the  table 
which  was  used  for  the  digital  output). 

1 LET  A=RDI (0,1) 

PROCESS  BASIC: 

Assembler 

RTE-B: 

data  a-e  acquired  by 

RD8TT  (channel,  bit  number,  variab’le) 

X CALL  RDBIT  (0,0, A) 

2.3.2  Input  of  words 


ADAPTS: 

Digital  data  are  acquired  by  OATAI  and  DATIF  using  channel  and  frame 
specifications. 

(see  2.1.1) 

BASEX: 

By  using  the  process  variable  INW  (register  number)  16  bit  binary 
data  and  by  using  IND  (register  number)  BCD  oriented  data  can  be 
transferred.  The  data  are  read  as  the  mantissa  of  a real  number 
with  exoonent  0. 

1 LET  A=INW(3) 


-143- 


j 


i 


BASIC  RT/11: 

— 

The  system  subroutine  "DIR"  (n,  variable,  control  and  status)  reads 
a 16  bit  word  from  an  input  register  and  stores  the  BCD  coded  value 
for  n=0  and  the  binary  value  for  n=0  in  the  variable. 

1 CALL"DIR"  (1,A,N) 

Another  possibility  offers  the  subroutine  "DRS"  which  reads  a 
sequence  of  digital  data  directly  or  under  clock  control  into  a 
buffer. 

"DRS"  (buffer,  n,  number,  clock  mode,  control -status) 

FPL: 

— 

Definition  of  a process  connection  with  activation  like  2.3.1 
DEF:  DIN:  INPU; 

CHAN:  0 

measurement  program: 

ACT:  INPU; 

LET:  A=INPU; 

INDUSTRIAL  BASIC: 

The  number  of  bits  in  RDI,  RDO  (see  2.3.1)  is  changed.  The  bit 
sequence  which  is  read  must  not  be  longer  than  12  bits 
(input  register  length) 

1 LET  A=RDI  (25,12) 

PROCESS  BASIC: 

1.  Using  the  EIN-macro 

2.  Using  the  DEG-macro  in  connection  with  the  INPUT  statement. 

(see  format  specifications  1.4.) 

(see  also  analog  input  2.1.) 

RTE-B: 

— 

Use  of  system  sub  program  RDWRD  (channel,  variable) 

1 CALL  RDWRD  (1,A) 
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2.4.  Digital  Output 

2.4.1  Output  of  single  bits 

ADAPTS: 

no 

BASEX: 

Like  in  2.2.1  using  the  process  variable  OUTB  (bit  number) 

1 LET  OUTB ( 1 ) = 1 

BASIC  RT/11: 
no 

FPL: 

specification  of  the  digital  output  module  for  outputting  single 
bits. 

DEF:  DOUT:  OUTP;  naming 

CHAN:  1; 

BITOUT:  OUTBIT(l);  naming  of  single  bits. 

measurement  program 

ACT:  OUTP 

LET:  OUTB IT  (1)=1; 

INDUSTRIAL  BASIC: 

Uses  digital  output  function  SDO  (bit  number,  number,  bit  pattern) 
(left  side  with  dummy) 

1 LET  D=SDO(1,1,0) 

PROCESS  BASIC: 

Assembler 

RTE-B: 

Uses  system  subroutine  WRSIT  (channel,  bit  number,  variable) 

1 CALL  WRSIT  (1,1, A) 


f-lM. 


J»/»V 


r- 


r 


■ 
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2.4.2  Output  of  words 
ADAPTS: 

Output  with  subroutine  DATAO  (see  2.2.1) 

BASEX:  ] 

Uses  process  variable  OUTW  (register  number)  for  binary  and  OUTD 
(register  number)  for  BCD  coded  digital  output. 

1 LET  OUTW  (2 ) =A 

BASIC  RT/11: 

The  system  program  "DOR"  (n,  variable,  control  variable)  sets  for 
n=0  or  clears  for  n^O  the  specified  bits.  The  output  control  variable 
then  holds  the  value 
1 CALL  "DOR"  (0,A,N) 

FPL: 

Uses  digital  output  module 
DEF:  DOUT:  OUTP 
CHAN:  1; 

measurement  program 
ACT:  OUTP 
LET:  0UTP=A; 

* (only  if  A has  an  integer  value) 

INDUSTRIAL  BASIC: 

i 

Uses  output  function  SDO  (see  2.4.1),  dummy  at  left  side. 

1 LET  D=SD0  (12,4,5) 

(bit  pattern  of  5 (decimal)  is  transferred  into  bit  12  to  15) 

PROCESS  BASIC: 

1.  Using  the  AUS-macro  for  formatted  output  (see  format  bit  1.4.) 
i 2.  Using  the  DAG-macro  in  connection  with  the  PRINT  statement 
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RTE-B: 

The  system  subroutine  WRWRD  (channel,  variable)  is  used 
1 CALL  WRWRD  (1,A) 

2.5.  Pulse  input 

ADAPTS: 

no 

BASEX: 

The  standard  peripherals  contain  a counter  which  can  be  read  by 
process  variable  INC  (number).  The  counter  is  started  by  ACTC 
(number)  and  stopped  by  HLTC  (number) 

1 CALL  ACTC(l) 

2 CALL  HLTC  (1) 

3 LET  A= INC ( 1 ) 

BASIC  RT/11: 
no 

FPL: 

no 

INDUSTRIAL  BASIC: 
no 

PROCESS  BASIC: 
no 

RTE-B: 

no 
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2.6.  Pulse  output 
ADAPTS: 

Output  of  a pulse  by  using  PULSE  (pulse  number) 

1 CALL  PULSE  (1) 

BASEX: 

Using  the  timer  pulses  of  defined  length  can  be  transmitted. 

The  process  variable  OUTT  (number)  sets  a timer  which  transmits  a 
pulse  of  the  desired  duration  after  ACTT(n). 

1 LET  OUTT  ( 1 ) =50 

2 CALL  ACTT  (1) 

BASIC  RT/11 : 
no 

FPL: 

no 


INDUSTRIAL  BASIC: 


PROCESS  BASIC: 


RTE-B: 

no 


\ 
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2.7.  Connection  of  other  peripherals 
ADAPTS: 

Using  assembler  routines  (see  1.6.) 

BASEX: 

Firstly  assembler  routines  can  be  coupled.  Secondly  by  the  statements 
EQUI,  EQUO  process  variables  (I  = Input  type,  0 = Output  type)  can 
be  defined  to  fullfill  the  necessary  machine  code  (Hexadecima1 
constants).  (New  process  variables  can  be  loaded  into  the  system 
to  save  EQU I- EQUO) 

line  number  EQUI  variable  name  = machine  code 

BASIC  RT/11: 
see  1.6. 

FPL: 

see  1.6. 

INDUSTRIAL  SASIC: 
see  1.6. 

PROCESS  BASIC: 

With  macros  DEG  and  DAG  also  non  standard  peripheral s ran  be 

defined. 

RTE-B: 

see  1.6. 
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3.  Externa]  interrupts 

Each  implementation  is  checked  for: 

3.1.  connection  program  parts 

3.2.  disable  and  enable 

3.3.  Interrupt  levels 

ADAPTS: 

Interrupt  treatment  in  BASIC  and  assembler  is  defined.  No  detailed 
description  for  further  evaluation. 

BASEX: 

Connection  of  program  parts 

The  statement  ON  INT  interrupt  number:  allows  two  possibilities  after 
the  Firstly  a branch  to  a predefined  program  or  secondly  the 
direct  execution  of  single  statements.  The  interrupt  number  is  kept 
until  it  is  redefined.  Each  connected  program  must  end  with  a STOP 
statement. 

Disable  and  Enable 

The  statements  ENAB  interrupt  number  and 
DISAB  interrupt  number 

allow  disabling  and  enacting  at  each  point  of  the  program. 

1 REM  MAIN  PROGRAM 

2 ON  INT  1:  GOTO  100 

3 ENAB  1 

100  REM  INTERRUPT  SERVICE 
110  .... 

200  STOP 

Interrupt  levels 

There  are  several  levels  with  hardware  priorities.  Interrupts  of  the 
same  level  can’t  interrupt  themselves  but  are  stored  and  executed 
using  the  algorithm  "smallest  number  first".  The  implementation 
uses  2 or  4 levels. 
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BAS1C  RT/11: 

no 

FPL: 

No  program  call  on  interrupt  exists.  For  analog  inputs  alarm  limits 
can  be  specified  (high  and  low  limits)  which  cause  a message 

DEF:  AIN:  INA; 

CHAN:  1 
PER:  5; 

, IRC:  10,  50 

ERG:  0,900,DEGF; 

ALM; 

1 HIAL:  750; 

LOAL:  50; 

The  units  are  0 to  900  degrees  Fahrenheit.  The  limits  are  50  F 
(LOw  ALarm)  and  750  (High  Alarm). 

INDUSTRIAL  BASIC: 

Connection  of  a program  part 

The  statement  CONTACT  n THEN  line  number  causes  the  jump  to 
line  number  if  the  contact  n changes.  The  service  programs  have 

t to  be  finished  with  DISMISS. 

Enable  and  Disable 

There  are  no  special  statements.  The  interrupt  is  enabled  by  CONTACT 
n THEN  line  number.  The  service  program  can  be  halted  and  the 
connection  can  be  solved  by  CONTACT  0 THEN  line  number.  The  line 
numbers  must  be  the  same  in  both  statements. 

1 REM  MAIN  PROGRAM 

2 CONTACT  1 THEN  100 

100  REM  SERVICE  PROGRAM 
160  DISMISS 
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PROCESS  BASIC: 

Connection  of  program  parts 

The  interrupt  definition,  stack  organisation  and  priority  assignment 
must  be  done  by  the  user.  The  macro  D IT  connects  the  program  with 
the  operating  system.  For  intermediate  storage  and  saving  of  the 
current  machine  states  each  priority  level  must  have  its  own 
stack.  (In  the  example  the  stack  is  defined  at  the  end  of  the  service 
routine.)  Interrupt  service  programs  must  be  finished  with  a VPE  or 
RIT  macro. 

Enable  and  disable 

The  macro  ISL  bit  pattern  is  used  to  enable  and  disable  the  speci- 
fied levels. 

DIT  Stacklist/  :Passing  of  stack  to  operating  system 
i MA INPROGRAM 

ISL  00  :Level  0 enabled  (bit  0 set) 

i INTERRUPT  SERVICE 
INTERRUPT  ... 

RIT 

STACK  $ 2 INTERRUPT  :Start  address  of  service  routine 

PSW  -1-30  :Stuck  level  0 (in  this  example  31  words  long) 

STACKLIST  BRI  00  STACK 
0 
0 

(Here  the  start  addresses  of  the  levels  must  be  stored.  The  sequence 
defines  the  priorities.) 

(STACK,  STACKLIST  and  INTERRUPT  are  labels) 

Interrupt  levels 

The  user  defines  the  priorities  of  the  service  programs  with  the 
sequence  of  the  addresses  in  the  "stacklist".  12  levels  are 

possible. 


RTE-B: 
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Connection  of  program  parts 

The  interrupt  source  can  be  defined  by  SENSE  (channel,  bit,  value, 
trap  number).  CALL  MPNRM  deletes  all  SENSE  definitions.  Coupling  is 
done  by  TRAP  trap  number  GOSUB  line  number.  The  service  program 
is  ended  by  RETURN.  Priorities  can  be  defined  by  SETP  (line  number, 
priority) 

Enable  and  Disable 

The  statement  CALL  ENABL  (lire  number)  enables  the  program  Dart 
from  the  specified  line  number  (which  got  an  interrupt  by  SENSE) 

CALL  OSABL  (line  number)  disables  the  program. 

1 REM  MA INPROGRAM 

2 CALL  MPNRM 

3 CALL  SENSE  (0,1, 1,1) 

4 CALL  SETP  (100,5) 

5 TRAP  1 GOSUB  100 

6 CALL  ENABL  (100) 

100  REM  INTERRUPT  SERVICE 
200  RETURN 
Interrupt  level s 

A scheduler  program  supervises  all  interrupts  and  tir*  dependent 
calls  (up  to  161  and  causes  execution  related  to  priority. 

4.  Treatment  of  time 

Remark:  In  general  the  treatment  of  time  correlated  statements  is  either 
of  type  "AFTER  interval  DO"  or  "AT  absolute  time  DO"  Th-  statements 
have  to  cause  access  to  a clock.  Three  examples  show  the  time  handling. 

It  is  distinguished  between: 

4.1.  Start  at  an  absolute  time 

4.2.  Start  after  an  interval 

4.3.  Repetitive,  time  dependent  execution. 


\ 
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ADAPTS: 


Uses  system  subroutine 

SCHED  ( hour  ) ( min  ) ( sec  ) ( line  number  ) which  is  of  the 

"AT  ...  DO"  type. 

Accessing  absolute  time  is  done  by  TIME  ( hour  ) ( min  ) ( sec  ) 


a)  Start  at  an  absolute  time  (14:30:00) 
1 CALL  SCHED  (14)  (30)  (00)  (100) 


b)  Start  after  a time  interval  (45  sec) 

1 CALL  TIME  (H) (M) (S) 

2 REM  CALCULATE  NEW  STARTING  TIME  = NOW  + 45  sec 

3 LET  S=S+45 

4 IF  (S>  60)  THEN  10 

5 LET  S=S-60 

6 LET  M=M+1 

7 IF  (M > 60)  THEN  10 

8 LET  M=0 

9 LET  H=H+1 

10  CALL  SCHED  (H)  (M)  (S)  (100) 

100  REM  SERVICE 
150  CALL  RESUME 

c)  Repetitive  time  dependent  execution 

Start  like  4.1.  or  4.2.  Up  to  19:15:00  the  service  routine 
should  be  started  every  15  sec. 

123  REM  SERVICE 

110  CALL  TIME  (H)  (M)  (S) 

120  IF  (H  19  AND  M 15)  THEN  300 
130  REM  CALCULATE  L I K£  (3) 

140  CALL  SCHED  (H)  (M)  (S)  (100) 

150  REM  SERVICE  START 

300  CALL  RESUME 


\ 
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BASEX: 

There  is  a statement 

AFTER  time  interval  : statement 

Tne  same  statements  like  in  ON  INT  ...  are  permitted.  In  this 
implementation  the  time  activations  are  of  lower  priority  than 
the  interrupts.  To  access  the  system  time  one  can  use  the 
system  variables  HOUR,  MIN,  SEC,  MSEC. 

a)  Start  at  an  absolute  time  (14:30:00) 

1 REM  CALCULATE  INTERVAL  FOR  START 

2 LET  TIME  = (60  * (14  *60  + 30) )- (60  #•  (HOUR«60+MIN)+SEC) 

3 AFTER  TIME  1000  : GOTO  100 

b)  Start  after  an  interval  (after  45  sec) 

1 AFTER  45000  : GOTO  100 

100  REM  SERVICE 
200  STOP 

c)  Repetitive  time  dependent  execution  with  time  limit 
Start  like  a)  or  b).  Up  to  19:15:00  every  15  sec. 

100  REM  SERVICE 

110  IF  HOUR  = 19  AND  MIN  = 15  THEN  300 
120  AFTER  15000  : GOTO  100 
130  REM  SERVICE  START 

300  STOP 

BASIC  RT/11: 
no 


# 


\ 
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FPL: 

Statements  for  time  control  are  WAIT,  WAIT  UNTIL  and  WAIT  UNTIL  OR. 

Multi  tasking  allows  the  establishment  of  tasks  into  the  WAIT  state. 

WAIT  only  stops  the  task  where  the  WAIT  is  programmed. 

Access  of  system  time  via  HOUR,  MIN,  SEC  system  variables. 

a)  Start  at  absolute  time  (14:30:00) 

DEF:  TASK:  SERVICE; 

WAIT  UNTIL:  HOUR  = 14; 

WAIT  UNTIL:  MIN  = 30 

DEACT:  SERVICE 

Main  program 
ACT:  SERVICE; 

b)  Start  after  an  interval  (45  sec) 

DEF:  TASK:  SERVICE; 

WAIT:  45; 

DEACT:  SERVICE; 

c)  Repetitive  time  dependent  execution 

Start  with  ACT:  SERVICE;  up  to  19:15:00  every  15  sec. 

DEF:  TASK:  SERVICE; 
waiting  like  a)  or  b) 

2 IF  (HOUR  f 19)  GOTO:  3 
IF  (MIN  f 15)  GOTO:  3 

GOTO:  4 

3 ... 

WAIT:  15 
GOTO:  2 

4 DEACT:  SERVICE; 
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INOUSTRIAL  BASIC 

The  statement  TIMER  <inverval  > THEN  line  number  is  of  the  type 
AFTER  ...  EVERY  ...  DO. 

TIMER  0 THEN  <1ine  number)  deletes  definition,  (like  CONTACT  0 
when  handling  interrupt).  The  statement  COUNTER  <number>  THEN 
<line  number)  is  nke  AFTER  ..  DO,  but  in  this  case  a counter  is 
set  in  hardware  and  then  decremented  until  content  = zero.  This 
causes  jump  to  specified  line  number.  Therefore  the  time  for  a 
decrement  must  be  known  and  offer  the  right  order  cf  magnitude 
to  be  used  in  the  program. 

Access  of  absolute  time  can  be  done  by  CLK  (n). 

(n  = 0 read  clock,  n f 0 set  clock) 

a)  Start  at  absolute  time  (14:30:00) 

(Assumption  one  count  = 1 sec) 

1 REM  MAIN  PROGRAM 

2 LET  Z=143000-CLK(0) 

3 COUNTER  Z THEN  100 

100  REM  SERVICE  PROGRAM 
110  ... 

160  DISMISS 

b)  Start  after  an  interval  (45  sec) 

1 REM  MAIN  PROGRAM 

2 COUNTER  45  THEN  100 

100  REM  SERVICE  PROGRAM 


150  DISMISS 

Repetitive  time  dependent  execution  with  time  limit.  Start  like 
a)  or  b).  Every  15  sec  up  to  19:15:00. 
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c)  1 REM  MAIN  PROGRAM 
2 COUNTER  0 THEN  500 


500  REM  SERVICE 
510  TIMER  15  THEN  500 
520  LET  Z = CLK(0) 

530  IF  Z > 191500  THEN  570 
540  REM  SERVICE  PROGRAM 


560  DISMISS 

570  TIMER  0 THEN  500 

580  DISMISS 

PROCESS  BASIC: 

Only  access  to  time  intervals  is  possible.  The  macro  IPZ  (programmed 
interrupt  after  interval)  causes  delayed  start  of  a priority  level 
like  AFTER.. DO.  Macro  VPE  causes  leaving  a program  level  for  the 
defined  time  and  then  start  again.  An  internal  counter  exists,  which 
is  incremented  every  three  milliseconds.  The  examples  do  not  show 
stack-  and  level  assignment  (as  for  interrupts). 

Start  at  absolute  time: 
unknown 


Start  after  time  interval  (45  sec) 
i MAIN  PROGRAM 

ISL  002  1 level  enabled 

IPZ  + 1 45  Start  level  1 after  45  sec 


t SERVICE  PROGRAM  LEVEL  1 
LEVEL  1 ... 

RIT 

(LEVEL  1 = Label) 
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Repetitive  time  dependent  execution  with  time  limit 

Start  like  b),  execution  every  15  sec. 

t SERVICE  PROGRAM 

BEGIN  IF  limit  THEN  END 

VPE  + 15 
GOTO  BEGIN 
END  RIT 

R.E-B: 

There  are  tne  system  program  TRNON  ( line  number  , time  ) and 
START  ( line  number  , time  ) like  AT  ..  DO,  AFTER  ..  DO.  The 
system  program  TIME  (variable)  accesses  absolute  time.  In  addition 
priorities  can  be  assigned,  (see  3.,  CALL  SETP) 

a)  Start  at  14:30:00 

1 REM  MAIN  PROGRAM 

2 CALL  TRNON  (100,143000) 

100  REM  SERVICE  PROGRAM 
150  RETURN 

b)  Start  after  45  sec. 

1 REM  MA.IN  PROGRAM 

2 CALL  START  (100,45) 

c)  Repetitive  time  dependent  execution  with  time  limit 
Start  like  a)  and  b).  Lvery  15  sec  up  to  19:15:00  execute. 

100  REM  SERVICE 

110  CALL  TIME  (T)  iT  in  sec  after  midnightj- 
120  IF  T > 19*  3600+15*60  THEN  190 
130  CALL  START  (100,15) 

140  REM  SERVICE  PROGRAM 


190  RETURN 


r 
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5 . Pa rallel  execution  of  programs 


It  already  has  been  mentioned  that  multi  programming  is  difficult  with 
BASIC.  But  for  some  applications  it  may  be  useful  to  run  a background 
program  in  BASIC.  How  the  implementations  deal  with  that  is  shown  below. 
(The  start  should  be  caused  by  program  not  by  clock  or  interrupt.) 
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INDUSTRIAL  BASIC:  no 

PROCESS  BASIC: 

The  macro  IPT  starts  a defined  level  which  must  have  been  enabled 
by  ISL. 

(Priority-  and  stack  assignments  are  left  out) 

(see  3) 

t PROGRAM  LEVEL  0 
ISL  002 
IPT  +1 

i BACKGROUND  PROGRAM  LEVEL  ; 

RIT 

RTE-B:  no 

6.  Synchronisation  of  program  parts 

This  is  necessary  if  continuation  of  a process  depends  on  one  or  more 
events  which  are  set  by  other  processes. 

ADAPTS: 

Using  WAIT  time  interval  only  allows  pseudo  synchronization 
BASEX: 

WAIT  numerical  expression  causes  GOTO  to  itself  if  expression  = 0 
(FALSE).  If  value  ^0  (TRUE)  the  program  executes  the  next  statement. 

Note  that  WAIT  does  not  enable  program  execution  for  lower  levels 
if  executed  in  a higher  level.  Therefore  this  statement  is  only 
useful  on  the  lowest  level. 
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100  REM  MAIN  PROGRAM  (wait  for  interrupt  but  only  1,5  sec) 

105  ON  INT  1:  GOTO  100 
110  ENAB  1 
120  LET  M=MSEC 

130  WAIT  FLAG  = 1 OR  MSEC  = M + 1500 
140  DISAB  1 

500  REM  INTERRUPT  SERVICE  FOR  INT  1 

550  LET  FLAG  = 1 
560  STOP 

BASIC  RT/11: 

The  system  subroutine  "WAIT"  (n)  causes  a halt  up  to  occurrence  of 

the  event  specified  by  n.  This  event  is  generated  by  hardware  which 

consists  of  a clock  and  a one-bit  input. 

n=0:  time  interval 

n=l:  trigger  signal 

n=2:  means  n=0  or  n=l 

120  CALL  "WAIT"  (1) 

FPL: 

The  statements 

WAIT  <time  interval> 

WAIT  UNTIL  <condition>  OR  <time  interval> 

WAIT  UNTIL  <condition> 

cause  a time-  or  condition  dependent  halt  of  the  task. 

Other  tasks  continue. 

DEF:  TASK:  TEST; 

WAIT  FLAG  = 1 OR  15 
(15  means  15  sec) 
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INDUSTRIAL  BASIC: 
no 


PROCESS  BASIC: 
no 


RTE-B: 

WAIT  <time  interval>  halts  the  program  for  the  specified  time. 
During  this  time  no  other  program  is  running.  Interrupts  are  only 
stored  and  are  treated  after  the  time  interval  (max.  30  sec). 

The  waiting  time  is  not  precise. 


7.  Error  treatment 

When  controlling  processes  it  is  important  to  avoid  system  stop  in  the 
case  of  an  error  but  to  treat,  the  error  by  program. 

ADAPTS: 

no 

BASEX: 

It  is  possible  to  start  an  interrupt  program  in  case  of  an  error. 
The  system  variable  ERR  holds  the  cause  of  the  error. 

An  advanced  implementation  will  use  an  ON  ERR  statement. 

BASIC  RT/11: 
no 


FPL: 

no 

INDUSTRIAL  BASIC: 
no 

PROCESS  BASIC: 


no 
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RTE-B: 

There  is  a parameter  defined  to  allow  error  treatment  by  program, 
(in  the  example  called  E) 

100  CALL  AIRDV  (5,  (1,  VI,  E) 

101  IF  E = ...  THEN  ... 

A "failure  option"  FAIL:  GOTO  line  number  can  be  connected  with  system 
subroutines.  The  system  variable  IERR  tells  the  cause.  FAIL  cannot  be 
used  with  BASIC  statements. 

100  CALL  TRNON  (2000,  122536)  FAIL:  GOTO  1000 

1000  IF  IERR ( X ) = 1 THEN  1100 

1001  IF  IERR ( X ) =2  THEN  1200 
(X  = dummy) 


i 


' 


i 
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Compar  isons 


1 . 1 Mnemotechniques 

Variables  start  with  a letter  (but  not  FN)  and  contain  up  to  32 
characters  of  letters,  digits  or  decimal  point. 

1 . 2 Objects  and  Opera, ions 

Real,  string  and  integer  (Logical  = integer).  Integer  and  real 
are  freely  mixed. 

1 . 2.  1 Text  Handling 

Text  handling  uses  string  variables  and  ASCII  literals. 

String  variables  are  identified  by  $ (ABC$). 

String  constants  are  identified  by  single  or  double  quotes  ('ABC', 
"ABC"). 

Comparison  and  concatenation  are  available. 

System  functions:-  CHAR,  LEN,  GAP,  VAL,  DATE,  TIME,  LINE, 
SEG,  STR. 


J 


r = — — 1 

-164- 


•I 


i 


i 


i 


1.2.2  Logic  Operations 

Logic  operations  are  applied  bit  by  bit  to  integers.  FALSE  = 0 
TRUE  0 0. 

The  operations  available  are  NOT,  AND,  OR,  XOR,  IMP,  EQV. 
Real  variables  are  converted  to  integers. 

1 . 3 Specification  of  Peripherals 

Up  to  255  logical  channels  may  be  used  and  are  referenced  by:- 

PRtNT  ^N, 

INPUT  ^N, 

where  N = 1 to  255 

1 . 4 Formal  Specification 

As  in  NCC  standard.  A string  (expression,  literal  or  line)  defines 
the  required  format  in  terms  of  literal  characters  and  moulds. 

For  example 

A#  = "A=+*^*  * B=+*.  **  C=  A***  D=+  * 

PRINT  USING  A$ , 20.2,  15.9,  "XYZPQ"  15 

produces 

A=  20.  2 B=  1 5.  9 C=XYZP  D=  1 . 5 E 0 ! 

The  functions  TAB,  GAP  and  LIN  are  also  used 

1 . 5 File  Handl  ing 

Two  types  of  file  exist,  ASCII  serial  and  random  access, 
i)  ASCII  serial  (discs,  readers,  CRT's,  etc) 

INPUT 

OPEN  name  for  OUTPUT  AS  FILE  channel  no. 
EXTENSION 

CLOSE  channel  number 

INPUT, PRINT  and  INPUT  LINE  operate  on  serial  files 


t 

i 
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ii)  Random  Access  (disc  only) 

CREATE  name  WITH  n RECORDS  OF  m AS  FILE  k 

OPEN  name  AS  FILE  k RECORD  SIZE  i 

CLOSE  channel  no. 

These  files  are  accessed  by:- 

GET  **n  RECORD  m INTO  array 

PUT  RECORD  m FROM  array 

All  files  have  a device  name  and  file  name 
i.  e. 

PR  = paper  tape  reader 

DK  : FRED  = file  FRED  on  disc  unit  DK 


Insertion  of  Assembly  Routines 

Any  function  or  sub-program  can  be  a machine  code  routine. 

The  routine  is  converted  through  the  assembler  and  then  a special 
program  into  a special  type  of  BASIC  line.  In  this  form,  the  machine 
code  functions  or  sub-program  are  manipulated  in  the  same  way  as 
normal  BASIC  lines. 

Additional  system  routines  can  be  also  incorporated. 

Segmentation  of  Programs 
No  CHAIN  facility. 

An  OVERLAY  statement  allows  specified  sub-programs  (parameterised 
subroutines)  to  be  assigned  to  a number  of  overlays. 

The  calling  mechanism  is  automatic  and  transparent. 

Sub-programs  do  not  have  to  be  in  overlays.  They  operate  on  their 
own  set  of  variables  plus  their  formal  parameters. 


e.  g. 

CALL  ABCD  (X  % , 22,  A#,  Y( , ) ) 


* 
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2 Process  - l/O  ] 

All  process  variables  are  scanned  and  converted  by  other  parts  of  *hi  j 
system  and  are  not  the  responsibility  of  BASIC. 

BASIC  may  access  any  process  variable  from  the  system  data-banks. 

Three  types  of  process  variables  are  recognised,  variable,  logical  an 
item.  There  are  three  associated  operators  (V@,  L@  and  l§-l  and  eac  1 
process  variable  has  a "point  number"  (an  integer). 

For  example 

X = A + V@20  + V@B%  (K+2) 

IF  L@K  GOTO 

Each  process  point  can  have  a system  name  and  system  functions  are 
provided  to  convert  between  point  names  and  point  numbers 

Process  outputs  are  oerformed  by  the  statements 

ITEM 

STORE  VARIABLE  xxx  IN  point  name 
LOGICAL 

' Note  that  there  are  two  operating  modes.  In  one  (development  mode 

any  STORE  statements  cause  a message  to  be  printed  giving  the  para- 
meters of  the  statement  but  no  output  is  performed.  In  the  ‘ormal 
mode"  the  statement  is  obeyed  normally. 


2.1.1 


I 

2.  L 2 Input  of  Sever, tl  Data  Values  without  Channel  Switching 
No  special  provisions. 

i 

| 2.1.3  With  Channel  Switching 

No  special  provisions. 


Analog  - Input 
Input  of  a Value 

Analog  values  are  accessed  as  real  variables  as  shown  in  above 
i.  e. 

X - V@  point  numbs ' 


S 

< 

t 

i 


\ 
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2.  1.4  Muliiple  Values  and  Channel  Switching 


No  special  provision 


Analog  Output 


Depending  upon  the  system, analog  outputs  are  performed  by  STORE 
VARIABLE  or  STORE  ITEM  statements. 


Digital  Input 


2.  3.  1 Input  of  Single  Bits 


Whether  a digital  input  is  one  bit  or  a word  is  implicit  in  its  point 
number. 


Hence,  it  is  referenced  by 


X = L@  point  number 


2.  3.  2 Input  of  Word 


X = L@  point  number 


Digital  Output 


2.  4.  1 / Single  Bits  or  Words 
2:  4.  2 

A digital  output  is  defined  as  a bit  or  word  by  its  point  number. 
STORE  LOGICAL  xxx  IN  poiht  number 


Pulse  Input 


Pulse  inputs  will  have  been  converted  to  variables  by  the  rest  of  the 
system 


X = V@  point  number 
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2.  6 Pulse  Output 

Not  a normal  form  of  output  on  K90. 

Would  be  handled  by 
STORE  LOGICAL  

2.  7 Connection  of  Non-Standard  Peripherals 

All  peripherals  supplied  with  a system  are  fully  supported  and  the 
system  is  device  independant.  Addition  of  a new  peripheral  by  a 
user  requires  regeneration  of  the  system  normally. 


3 External  Interrupts 

These  are  not  directly  controlled  by  BASIC.  Any  program  in  the 
system  can  be  started  by  an  interrupt  as  defined  at  system  generation 

I i 

Priority  and  dead-time  are  a function  of  the  priority  assigned  to  the 
program  and  normal  system  multiprogramming  constraints. 


I ' 


•. 


! 


4 System  Time 

System  routines  are  available  to  start  any  programt- 
i)  after  a time  delay 

i i)  at  a specific  t ime 

eg 


CALL  START  (program  no.  , data,  time,  time  units) 

CALL  SCHED  (program  no.  , data,  hours,  min.sec) 

A program  may  be  repetitively  scheduled  by  an  operator  request. 

This  may  commence  at  any  point  within  24  hours  and  have  a repitition 
rate  between  1/256  sc  - and  24  hours  in  units  of  1/256  sec. 

A program  may  also  be  delayed  by:- 

CALL  WAIT  (time,  time  units) 


5 Parallel  Exectuion  of  Progr ams 

K90  is  a multi-programming  system.  At  any  time  up  to  127  programs 
may  be  time-sharing  on  a priority  basis. 


- T 


t 


\ 
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K90  BASIC  has  two  modes,  development  and  formal.  In  development 
mode  the  BASIC  program  is  not  permitted  to  affect  the  rest  of  the  system 
and  operates  at  a background  level.  In  formal  mode  a BASIC  program 
may  have  any  priority  (256)  and  interact  with  tne  system  in  the  same 
manner  as  any  other  form  of  program. 

Every  program  has  a name  and  a number  and  system  routines  convert 
between  the  two  forms. 

Any  program  may  start  any  other  and  pass  one  piece  of  information, 
i.  e. 

CALL  START  (program  name,  data,  0,  0) 

In  addition,  the  start  may  be  time  dependant  as  shown  in  section  8.  A 

6 Synchronisation 

No  formal  synchronisation  mechansim  is  available. 


I < 

I , 


7 Error  Treatment 


The  system  will  supply  default  values  for  non-fatal  errors  (ie  over- 
flow). 

The  user  may  trap  any  error  by:- 

ON  ERROR  GOTO  - - - 

Two  variables  define  thererror. 

ERTYPE  = a number  defining  the  error 

ERLINE  = the  line  number  causing  the  error 

On  occurrence  of  an  error,,  the  user  may:- 

i)  Ignore  the  error  and  restart  at  the  line  causing 
the  error  or  any  other  line 

i.  e. 

RESUME  at  same  line 

RESUME  100 

ii)  Allow  the  system  to  handle  the  error  as  if 
ON  ERROR  GOTO  has  not  been  used 

ie 

GOTO  SYSTEM 

In  the  case  of  process  information  secondary  information  is  available 
on  the  validity  of  the  values. 


/ 


\ 
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CASIC  - Schlumberger 


CASIC  is  a single  user  conversational  programming  language  for  CAMAC  peripheral 
using  the  standard  statements  of  BASIC  and  some  extensions  - 

| 

] - Extension  of  the  algorithmic  part 

1.1.  Mnemotechmques 

Symbols  use  the  first  6 alphanumeric  characters  of  an  alphanumeric 
sequence  starting  with  a letter 

1.2.  Objects  and  operations 
used  data  types  : 

- integer  numbers  - octal 

- decimal 

i.e  - if  the  special  character/^  is  used  the  value  typed  in  is  for 
CASIC  in  octal 

i.e.  2000  means  1024 

- OCT  and  DEC  functions  can  be  used  in  a PRINT  statement 
to  output  numbers  in  octal  or  decimal  format 

- real  number 

- text  handling  : NO 

- bit  manipulation  . AND,  OR,  XOR,  NOT,  SHIFT  are  implemented 

by  functions 

i.e  - AND  (A,  OR  (B,  C)  ) 

- logic  operations  are  available  with  bit  manipulation  in  conjunction 
with  the  IF  statement. 


-171- 


' 


13.  Specification  of  peripherals 


- for  CAMAC  : by 


i 


i 


y 

\ 


i 

5. 

» 


DCLCAM  name  of  unit,  . . . (declaration  statement) 
and  STATION  name  of  unit  = Camac  address  (assignment  statement) 
l/O  can  be  activated  in  an  arithmetic  expression  or  not,  using 

the  name  of  unit. 

- for  non  CAMAC  peripherals  by 

PRINT  or  INPUT  (available  only  for  teletype) 

1.4.  Format  specification 

- for  CAMAC  : NO 

- for  teletype  : 

- input  format  is  implicit,  depends  either  on  the  type  of  the  variable  decla- 
ration, or  on  the  character  preceding  the  input  value 

- output  format  is  either  implicit,  or  using  OCT,  DEC,  BTD,  DTB  functions. 

1.5.  File  handling  : No 

16.  Insertion  of  assembler  routines 

assembler  routines  can  be  loaded  at  system  generation  time.  They  have 
t be  declared  by  DCLFNT  and  then  they  can  be  called  like  any  right  function.  16 
numerical  parameters  can  be  passed. 

1,7,  Segmentation  of  user  programs  : NO 

2 Process  l/O 

Handles  only  CAMAC  peripherals 

input  and  output  are  always  for  a single  value  in  digital  format 
analog  input  or  output,  pulse  input  or  output  are  available  with  the 
corresponding  CAMAC  module.  All  modules  are  handled  in  the  same  way. 

Fbr  that  purpose  three  types  of  peripheral  statements  : 


f 

t 


1  - Peel aration  statement 


A symbolic  name  must  be  assigned  to  each  CAMAC  register  used  in  the  program 
and  any  reference  to  a CAMAC  register  must  be  done  with  this  symbolic  name.  T 
form  is  : 

DCLCAM  symbol,  symbol 
i.e.  DCLCAM  ADC,  PULSE,  SCALE(3).  PREC 

2 - Definition  statement 

the  statement  STATION  is  used  to  indicate  the  geographical  position  of  a CAMAC 
register,  the  form  is  : ST  A.  TION  symbol  = (B , C,  N,  A ) 

B for  branch  number 
C for  crate  number 
N for  address  in  the  crate 
A for  sub-addresa 

i.e.  STATION  ADC  = (0.  1,  1,  0) 

STATION  PULSE  = (0,  1,  2.  0) 

FOR  I = 1 TO  3 
J = I + 2 

STATION  SCALE(I)  = (0,  1,  J,  0) 

NEXT 

STATION  PREC  = (0,  1,  6,  0) 

3 - Execution  statement 

3 , j . OPERATE  statement  for  CAMAC  modules  and  CAMAC  crate 

actions 


3.1.  a.  to  test,  initialize,  enable,  disable  modules  or  crates, 
nemonic  symbols  are 


TSTL,  CLRL,  ENBL,  DISBL  for  modules 
and  INIT,  CLEAR,  DISHIB,  INT1IB,  ENABLE,  DISABLE  for  crates 
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3.1.b.  other  OPERATE  functions  are  executed  with  the  general 
statement  OPER  associated  to  a function  value  as  an  argument  of  the  CAMAC  register 
name  - 

i.e.  OPER  ADC  (26)  enable  the  CAMAC  module  register  named  ADC, 
since  CAMAC  function  26  means  "enable". 

3 , 2 - Read/write  statement  like  in  BASEX  mentionning  the  CAMAC 
register  anywhere  in  the  program  in  conjunction  with  a CAMAC  function  code.  The 
corresponding  process  is  executed. 

i.e.  A = ADC  (^)  means  'read'the  last  value  of  the  process  variable 
ADC,  with  the  CAMAC  function  and  'store1  this  value  in  the  normal  variable  A, 
and  'initialize'  a new  conversion  if  ADC  is  an  analog  digital  converter  as  in  this  example. 

The  philosophy  is  very  similar  to  BASEX  however  there  are  32  kinds 
of  CAMAC  functions  that  can  appeared  and,  in  order  to  limit  the  number  of  declara- 
tion statements,  the  type  of  process  (given  by  the  CAMAC  function)  is  defined  at  run 
time  . 

3 - External  interrupts 

3.1.  Connection  of  a program  segment  with  an  interrupt 

the  statement  ; ONI  .A  M name  of  the  process  variable  DO  line  number,  causes 
a jump  to  line  number  if  the  corresponding  interrupt  occurs  - 
the  service  programs  must  be  finished  with  CONTINUE. 

3.2.  Disabling  and  enabling  of  interrupts 

the  external  interrupts  are  handled  with  the  CAMAC  functions  8 (test  interrupt), 

10  (clear  interrupt),  24  (disable  interrupt),  26  (enable  interrupt)  using  OPERATE 
statement  or  the  corresponding  mnemonics. 


3.3.  Interrupt  levels 


unknown 


- Svstem  time  NO 


5 - Parallel  execution  of  program  . egments  NO 


- ,iy  nchrom  sation  of  program  segments  NO 


7 - Error  treatment 


; statement:  ON  ERROR  Do  line  number,  allows  the  jump  to  the  mentionned  line 
lumber  when  the  CAMAC  X error  o.  its, 
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1 1 . Other  Li terature 


zu  BASEX:  "Hohere  ProzeB-Sprachen  f Ur  kleinere  Rechner  - das  Beispiel 


BASEX",  Lecture  Notes  in  Computer  Science  12,  S.  436-446, 

1974,  Springer-Verlag 

Beschreibung  der  ProzeBsprache  BASEX 

Interner  Bericht  C-25,  Fak.  Physik,  Uni  Freiburg,  1974 

zu  Process-BASIC:  "Process-BASIC  - Ein  Programmiersystem  f Li r ProzeBlenkung 

mit  KLeinrechnern" 

Lecture  Notes  in  Computer  Science  12,  S. 425-435,  1974 
Springer  Verlag 

CAS IC- 1 1 B : BASIC  Extension  for  CAMAC,  Schl umberger  1975 

" Interpreters  and  CAMAC" 

Extensions  to  BASIC,  Tate.G.R.,  Dawson, W.K. 

Interne  Berichte  vom  Nuclear  Research  Centre,  Univ.  of  Alberta,  Canada 


"Draft  for  Minimal  BASIC",  X3J2  committee  1974 

"Specification  for  Standard  BASIC",  G.M.  BULL,  W.  FREEMAN,  S.J. GARLAND, 
NCC  Publication 

"Introduction  to  BASIC  Programming",  KEMENY,  KURTZ 
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User‘s  guide  for  writing  good  BASIC  programs 

The  current  trend  in  software  is  towards  structured  programming.  This 
implies  hierarchical  top-down  program  design  as  well  as  clean  definitions 
of  the  interfaces  between  parts  of  the  programs.  Reduction  of  programming 
errors,  easier  documentation,  program  maintenance  and  interface  definition 
for  parallel  programming  are  the  main  advantages. 

BASIC  as  language  does  not  support  structured  programming  but  one  can 
improve  the  quality  of  BASIC  programs  by  following  some  general  rules. 

1.  Modularity 

A)  Break  the  program  into  functional  blocks. 

(mainroutine  - subroutines) 

2.  Simp! icity 

A)  Make  the  logical  flow  of  the  program  as  simple  as  possible  (in  a 
"FOR-NEXT"  LOOP  do  not  arbitrarily  transfer  control  out  of  the  loop 
with  "GOTO's").  The  same  is  true  for  subroutines. 

8)  Use  one  line  for  entry  into  a specific  subroutine  and  larger 
functional  parts  of  the  program. 

3.  Readabi 1 i ty 

A)  Make  the  logical  flow  of  the  program  obvious  from  the  listing. 

Don't  use  remarks  to  excuse  obscure  logic.  Make  the  logic  clear  and 
use  remarks  to  clarify  the  role  of  the  logic  within  the  complete 
program. 

B)  Separate  subroutines  froi  the  program  on  the  listing  by  using  blank 
REMARK  statements. 

C)  Use  remarks  to  completely  identify  the  function  of  each  subroutine. 

D)  Then  in  the  listing  write  all  of  the  subroutines  last  so  they 
appear  last.  Write  the  main  program  so  that  it  flows  logically  from 
its  first  line  to  its  last.  Backwards  jumps  should  only  occur  at  the 
end  of  a loop. 

Example: 


LIFT 


TRIG-S  PR/P4/S9  P<>:?9 

IPP  RE"  A NGlE-S IDE-F I HE 
IIP  LET  P - 3.14159265 
I2P  DEE  FND(X)  : X*P/|80 
UP  PEE  FNS(X)  : SIN(FND(X)) 

. HP  PRINT  "ANGLE",  "SIDE",  "SIDE",  "THIRD  FIDE",  "CASE  2" 
UP  READ  8,  X,  Y 
ISP  PRINT  8,  X,  Y, 

1 TP  let  S - X*  ENF  (8  ) n 
I BP  IF  S > I THEN  ?»P 
|9P  IE  S : I THEN  J2P 
195 

2PP  RE"  TWO  POINTS  OF  INTERSECTION 
21  P LET  T : S/SORC  I-St2) 

22P  LET  C r ATN(T)*IRP/P 

, 23 P LET  A r 18P  - B - C 

2AP  GOSU8  J7P 

258  LET  C : 188  - C 

260  LET  A : IBP  - 8 • C 

270  G0SU8  J 70 

280  GO  TO  UP 

285 

2R P RE"  NO  POINT  OF  INTERSECTION 
I SP?  PRINT  " NONE",  " NONE" 

310  GO  TO  UP 
315 

32P  RE"  ONE  POINT  OF  INTERSECTION 
330  LET  A : R0  - 8 
34P  GOSUR  370 
350  PRINT  " NONE" 

36P  GO  TO  150 
365 

( 370  RE"  ANGLE-SIDE-ANGLE  ROUTINE 

, 380  LET  l r X*FNS(A  )/S 

390  IF  Z P THEN  420 
4PP  PRINT  " NONE", 

410  RETURN 
420  PRINT  Z, 

430  RETURN 
440 

45  0 DATA  60,  10.  8,  60,  IP,  9,  60,  10,  II 

460  DATA  120,  10,  8,  120,  IP,  9,  120,  10,  II 

470  DATA  90,  3,  5,  60,  5,  5,  30,  IP,  5 

999  END 


i 


REPORTS  ON  SOME  EXISTING  AND  PROPOSED 


PROCEDURAL  LANGUAGES  IMPORTANT  IN  THE 
DEVELOPMENT  OF  THE  LTPL 


The  six  languages  described  herein  have  all  been 
considered  in  the  deliberations  of  the  LTPL  Committee. 
Of  particular  importance  has  been  RTL/ 2 and  PEARL.  The 
pertinent  Workshop  Minutes  references  are  as  follows: 


1.  "A  Language  for  Writing  Real-Time  Systems  - LTR," 
Minutes  of  the  Third  Meeting  of  the  Purdue  Workshop 
on  Standardization  of  Industrial  Computer  Languages, 
PP . _T1'9TTT5“  


2.  "Some  Proposals  for  RTL/2,"  Fourth  Workshop  Minutes , 
pp . 291-312,  by  J.  G.  P.  Barnes 

3.  "PEARL,  the  Concept  of  a Process  and  Experiment- 
oriented  Programming  Language,"  Ibid , pp . 162-175, 
by  J.  Brandes,  S.  Eichentopf,  P.  Elzer,  L.  Frevert, 
V.  Haase,  H.  Mictenderf,  G.  Muller,  and  P.  Rieder . 


4.  "Industrial  Programming  Language  - LAI,  " Ibid , 
pp.  145-266. 


5.  "Elementary  Description  of  the  Features  of  the 

PROCOL  Language,"  Minutes , Seventh  Workshop , pp . 205- 
209,  217-233,  251-263,  by  G.  Louit. 


6.  "Development  of  a Process  Control  Language  - PCL," 
Minutes , Ninth  Workshop , Appendix  V,  pp . 230-237, 
by  H.  Kuwahara,  T.Hayashi,  K.  Fukuoka,  and  T. 
Bandou. 
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SEGA 

1 I NT RO DUCT  ION  - 

LfR  uses  Algol  as  background  with  special  posslt 
for  solving  real  time  problems. 

It  Is  associated  at  run-time  with  a standard  suf 
(or  monitor)  written  separately  which  deals  with  schedullr 
the  tasks  and  their  environment  : events,  resources,  Inpul 
output,  "dynamic  data". 


2.-  DATA  - 


2.1.-  Elementary  classes  - 

- arithmetic  variables  -real  (floating  point) 

-Integer  (short,  normal,  Ic 

- logical  variables  (or  bit  strings)  (short,  normal, 
with  bit  access . 

- boo  lean  variables 

- character  string  variables  with  character  access. 

- guajj  ty_va  r I_ab|es  (status  variables)  : variables 
one  of  a limited  set  of  different  values  declared 
symbolic  names  and  called  attributes. 

(These  variables  can  be  considered  as  an  e> 
of  boolean  variables). 


G ESA 
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- Rc  f erence_va  r|aM  es  : variables  used  to  access  the  ele- 
ments of  a set  (Indirect  adresslng) 

( see  below). 

2.2.-  Data  structures  - 


- Arrays  : static  structures  of  same  type  data 

- Set  : dynamic  structures. 

Set  declaration  gives  a template  using  classical 
variables  declaration. 

At  run-time,  elements  corresponding  to  this  tem- 
plate can  be  created  and  erased.  Reference  variables  wik 
their  operators  are  used  for  accessing  a given  element  of 
a set.  The  supervisor  deals  with  - dynamic  data  (memory 
allocation,  linkage). 

2.3.-  Real  time  data  (or  program  contrcl  data)  - 

- Event  : It  Is  a concept  with  pulse  property  : Its  acti- 

vation has  meaning  only  for  the  taskawaltlng  It. 

- Resource  : It  Is  a concept  with  state  property,  associa- 

ted with  a service.  A service  can  be  a device  or  a piece 
of  software. 

A service  and  Its  resource,  can  have  one  or  seve- 
ral users.  The  resource  can  be  it  d for  control  synchroni- 
zation of  this  service. 


PROGRAM  STRUCTURE 


An  LTR  program  Is  a list  of  articles. 

3.1.-  Data  articles  - 


In  this  type  of  article  appear  only  declarations 
and  their  Initializations.  Da  I a declared  In  data  articles 
are  global  and  can  be  used  In  any  other  article.  All  de- 
clarations can  appear  In  it  and  set  declarations  can  appear 
only  In  these  articles. 

3.2.-  Procedure  articles  - 


It  Is  the  same  notion  as  subroutine  In  Fortran. 
Data  declared  In  such  an  article  are  local.  (Accesses 
limited  to  the  internal  blocks). 

Use  of  rea I time  tools  Is  limited  In  this  article 
because  they  are  not  reentrant. 

3.3.-  Process  article  - 


Writing  Is  formally  thesame  as  for  procedure  arti- 
cle but  Implementation  Is  different  to  get  reentrant  code. 
Local  data  and  parameters  belong  to  a task  i.e,  at  each  pro- 
cess acllvation  (run-time  allocation). 

Data  declared  In  a process  article  are  local. 

All  real  time  tools  can  be  used  and,  Interesting  pro- 
perty, events  and  resources  can  be  declared. 
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Dynamfc  event  and  resource  are  thus  obtained. 

3.4.-  Inter  program  data  communications  - 

- by  global  data  (declared  In  a data  article) 

- parameters  In  procedure  and  process  call  (call  by  address 
or  reference,  cal!  by  value). 


4.-  COMMUNICATIONS  BETWEEN  AN  LTR  PROGRAM  AND  THE  STANDARD  SL'Ptr.y  1 


4.1. -  A process  call  creates  a task  with  a given  priority.  This 

priority  Is  used  by  the  supervisor  for  task  scheduling. 

- OPENED  Call  : the  calling  task  goes  on. 

- CLOSED  Call  : the  calling  task  stops  and  will  be  terminate 
only  when  the  called  task  Is  executed. 

The  supervisor  deals  also  with  events  and  resour- 
ces for  task  scheduling. 

4.2. -  Supervisor  deals  with  dynamic  data  for  creating,  erasing 

elements  of  a set  and  gives  the  L.TR  program  reference  value 
for  accessing  these  elements. 

4.3. -  Event  activation  and  event  expression  awaiting. 


4.4.-  Resource  possibility  : reserve,  free,  blocked,  deblocked. 


V 
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4.5. -  Symbolic  naming  of  an  interrupt  level.  Association  of  a 

procedure  article  to  this  name.  Control  of  the  status  of 
an  I nterrupt  I eve  I . 

4.6. -  Input  - Output  - 

- Symbolic  naming  of  a given  address  device. 

- Input  - Output  commands  with  the  following  parameters  : 

- symbolic  name  of  the  device 

- command  to  execute  (quality) 

- buffer  name 

- error  boo  I ean 

- resource  name  for  control 

- logical  variable  name  (bit  string  to  deal  with 
a poss  I b I e error) . 


The  supervisor  deals  with  storage  allocation. 


CONCLUS ION  - 

) 

The  supervisor  Is  ready 

- The  compiler  and  system  will  be  running  about  June  1970 

- No  overlay  In  this  Implementation 

i 

- Target  language  : assembly  language  of  the  CM  Iris  50 
computer  ( - 360.40). 

i 

\ .../... 


i 

t 
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- Supervisor  size  (without  tables)  » 10  K bytes 

- Compiler  size  ■ 128K  bytes. 
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1 lirfflODUCTION 

Several  implementations  of  sil'l/ 1 have  now  been  completed  and 
considerable  oxp  rienQf  In  the  use  of  the  lan  uagt  haj  t en 

Tills  note  su;  t e.  t.  s :y..io  :tlt'  rations  ..hich  • re  probably  d<--s irable 
in  order  to  improve  efficiency  and  acceptability  of  the  language. 

Sone  of  the  sup  • stior.s  made  h re  might  be  considered  -<n  anathema 
to  the  Algol  ?de-)ij  r.t;  however  . c nee  1 a practical  pro.;  ra waning 
language  and  not  a beautiful  ideal. 

The  aofi.os tions  re  not  coi.-pleto;  it  is  hoped  to  issue  further 
sugye.  tion.  covering  such  ar  a;  . : ..  . ti  ...  lis  to  U 

issued  .ow  in  orti  r th  t the  reactions  of  potential  users  may  be 
judged . 

A question! w.  ire  i:  included  in  an  appendix  and  readers  might  find 
th :s  a su  table  medium  in  which  to  express  their  comments. 


2 STYLE 

It  is  a feet  o'1  life  that.  Algol  based  languages  suffer  badly  when 
represented  using  com  only  available  character  sets.  The  general 
le.  ib'lity  of  .<TL  text  as  it  appears  on  line  printer  listings  and 
its  convenience  for  typing  would  be  improved  by  the  following 
alterations. 

2.1  Replacement  of  square  brackets  by  round 

3 pure  brackets  re  not  essential  for  the  analysis  of  RTL  text 
although  they  ore  helj  *ul  to  the  human  eye.  However,  the  SBC  : 
character  s t currently  -veilable  on  System  4 and  360  line  printers 
joes  not  have  them  an  have  rr sorted  to  the  use  of  | and  "J  which 
•S>  vo  . ,v  the  j ast  do  not  i:  ■ rove  legibility . 

i;ote  also  that  some  pr<  ra  -.is.,  languages  do  not  logically  distinguish 
: *on  ‘unc  ■ p : entr  POP— 2 Tf  L n/ 1 

2.2  R e s c r v e d ..or d s 

As  interactive  ccrvu  Ar  i;i  .raises  more  and  more  highly  qualified 

selv  ogra  text.  It  is  thus  most  desiral  c 

that  1 is  should  lo  ar.  painless  as  possible. 

O.-r  ex  (erienoo  with  various  formats  has  .indicated  that  thr  current 
st;  !.©  (•'.  ..  r er  to  either  quote  inclui  ten  (e.r.  1 

r uncierli!vpS  (o.  . lv  '-'S'  tr  in),  however  the  ‘ symbol  is  in  shi‘ t 
case  on  teletypes  ( lthu-.i  r.  ip,.  b>  tic  on  029  card  punches),  and 
thus  not  very  convenient. 
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Tt  is  auf  ested  therefore  tint  the  various  language  words  be  r rer.eC 
and  not  available  as  identifiers.  ! nJ  at  be  re:  1 that  this  i 
render  t • ri  ■ i nvr rs 

u ymbols  in  - they  . 1 i 1 ; n<  >r  by  thi  pi  r. 

Precedents:  1 1/ 1 , ?0  TLiAK , : OP-2,  TI  L. 


2.3  St  r -s 


The  :q  bole  available  to  represent  pairs  of  string  :uot  s are  not 
v y bis  1 tory . I'he  0 irr<  £ J ar<  :i  fit  Lt  to  r 

existence  of  1 su  • ts  th  v;i  mi  hi  ‘oil on  Pl/l  and 

use  the  suae  symbol  for  openin  an  . closing  quotes. 

.In  o:  .bedded  quote  :ould  be  re,  r seated  by  a pair  of  Quotes  as  in 
1 1 / 1 . 10  avoi  so  r diffii  Lties,  a v “nin  could  be  issued 

if  a novline  occurred  in  a string. 

Spaces  in  strings  will  be  denoted  by  the  underline/bra  k e racter 
(ISO  5?) . This  is  printed  var ' usly  as 


2. . 4 B 'tes 


The  t o char  will  be  renamed  by  c . This  is  to  emphasize  the  n t 
that  a byte  is  merely  an  unsigned  integer  (.$  255 ) and  need  not 
necessarily  denote  a character. 


3.1  Proccd'ire  nesting 

The  current  implementation  allows  nastily  to  a total  cv  th  of  4. 
TOTTRAi!  allows  only  1 and  is  I mown  to  be  ina  1 ' :o -to.  in  excessive 

■ llo.rnce  for  res  tin ; implies  inefficiencies  ir.  impler.O' tution  ar.l 
is  one  of  tie  pr  bles.s  with  Algol  60  ( ,hich  alio,, s an  infinite 
number) . 

experience  suggests  that  wher  as  4 levels  have  proved  us  “ul  they 

■ re  not  necessary . It  is  su  ested  1 t 2 levels  be  considered. 

Separate  control  routines  for  external  and  intern'. I procedure  c -.1  < ; 
be  ; rov ided,  hes  1 :cnsid srab  Ly  fa, "ter than  the  r ,.t 

routines,  the  code  of  all  'procedures  would  be  a .ora  shorter  and 
the  stack  space  required  would  be  2 words  loss  ~r  lin  ceil. 

3.2  Inner  blocks 

' / 1 has  LI  bl  ocks  xcept  pr  i ies.  'his  i: 

oartly  historic  because  it  ,,  's  not  al ! o..  d in  3.  (An  inner 
loci:  is  like  a compound  statement  but  with  eelnrations).  In 
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order  to  obtain  tt  • full  benefit  of  ad  ress  variables  (see  5.1 ) am1 
r i ty  it  is  propose  1 . nn<  r bio  :k-s  t 

It  is  1 noted  hoi  Lw  r :ks  not  coni  inii  irr  i rations 
i ' : i<  1 Le  I ‘fioiei  tly  ! t run  time  by  treating  the  decl  r;  tS 

as  if  the;  r,  re  t fci  outer  1 ' for  all  purposes  other  than  copes, 

-uch.  nn  i.ru  or  block  ,-.oulu  not  then  count  as  a level  as  far  as  tiie 
nest  in.  • r- ."triot'i  on  is  concerne.  . 

3.3  -v.  ocific  i ions 

Delete  y 'Jug  lei.  is  th.  • cot.  on  c.a so  and  use  ref  or  to  senate 

the  by-n-'-cio  ; ra-.:oter. 

Precedents:  Algol  6 , If?. 


t 

I 

I 


i 

< 
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3.1  ’’’unction  designators 

Prograr.i’i  rs  often  r.iis-use  function  designators  v/ithin  the 
oorrespon.'-lRg  procedure  declaration.  A construction  like 

RiTiR;  ( < expn  > ) 

would avoid  the  necessity  for  the  co..  oiler  to  allocate  space 
''or  the  designator  nd  alio  'lexibi  t . Th  • ffe c€  uld 

1 e to  eva  1 : 1 xpression  an<  xit  from  1 procoduri 

the  value  as  r'-sult. 

Tn  non  lyre  procedures  tie  statement 


R Ail' 


would  bo  a llowcd  to  denote  e.  it. 


Precedent:  PL/l , PC P-2. 


4 ARRAYS 

9 

4.1  Lcv.-er  be  nds 

* 

I 

. serious  inefficiency  in  TL  (co  pared  with  f r say)  is  the  need 
for  a pair  of  words  to  handle  arrays.  This  r ates  ti-uaeter  sr  io:.e  s 
ral  r . The  f In  pr  sals  en:  single  v/ord 

and  still  retain  tic  securit  fouturts  of  RTL  which  ! vs  hern 
valuable;  T c lower  bound  of  all  arrays  to  be  fixed,  '-'ach  urr  v;'.1 1 

l tier  be  stored  thu; 


and  the  £ ingle  base  r.rress  will  the:,  be  usd  to  access  the  elements 
and  the  n 1 . isei  bonus  ni  be  th<  I ity  ' s«  ■ 

length  of  an  ar  ay  in  the  language  by  on  ' x;  ression  of  -she  fora 

len,  tk  ovg.  5 doi.tii'ier  > 

this  uil  L sav<  I h<  of  t:  is  a sc  irat<  ranel 

when  necessary. 

; v : ; i-  iii  siona]  r *ays  . ' ; ' 1 truly  i rrays  of  a 

T te  - an  i i ■ of  . ub  rrays  can  remain  as  now.  Koti  t ti  L< 
operator  can  be  a _ lied  to  any  substructure  of  a cul ti-d inens lore.  1 
array . 

It  v;  ill  be  not < that  3 1 e of  one  Leh  n:  ion  . arrays  t e 

v ent  sccuri  t - hat  5 . n 

0 i . jer  in  >f  si  3rin  ti-  Lmi  n3  i oi  1 rr  y 

all  the  bounds  ..ust  o individually  ciiec-.cd  and  not  the  fin-J. 

re:  nly.  S3  ilarl,  :heckinj  ist  bt  xt:  :tin 

slices.  his  is  obviously  g ng  to  c som<  pr  ran:  t 

] but  I think  : i ti-dia  arr  $ s are  not  used  to  such 

that  this  .is  too  serious. 

Finally  there  is  the  qu-  stion  of  strings.  The  above  propos- 
lead  us  to  abandon  the  read  .nly  protection  currently  pr  v ■ icc.  I 
do  not  think  that  this  L:  serious,  ho  code  can  be  ccrru.  te  - c 
the  string  ■itself.  I.'ote  also  that  since  the  length  of  the  s rii. 

.ill  no.,  be  available  the  ter  inatin  2;  5 can  be  omitted;  this 
ins  •J.l-  :y s seemed  a curiosity  anyway.  The  coupil rr  will  lor.  rr 
able  tc  share  stri  : unless  identical;  : . ; f th 

bo  enormous. 

In  summary: 

PROS 

(i)  Simpler  parameter  passing 

(ii)  Length  opera  or  available 

(iii)  here-  compact  structure  in  1 dim  case 

(iv)  255  anomoly  in  strings  removed 

(v)  Lore  compact  cociln  in  1 dim  case 

(vi)  Shorter  compiler 

COliS 

(i)  Lower  bound  fixed 

(ii)  Lows  compact  structure  in  . ulti  dim  case 
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(iii)  Sic  . er  ,:tor  ■ o In  :..ulti  din.  case 

(iv)  Fo  protection  for  strings 

(v)  Loss  compact  coding  i.  n.ulti  dim  case 

Once  it  is  establi  shed  that  the  loner  'hour.-,  be  fixed  the  ■ no.  tion 
•.arises  should  it  be  0 (like  Autocode)  or  1 (like  Fortran)? 

In  favour  of  0 

(i)  More  natural  for  systems  programming  in  code  but  not  sure 
about  high  level  languages. 

(ii)  Freedom  t start  at  1 and  merely  , waste  a location  (but 
extravagant  to  do  this  for  matrices) 

(;..:./)  i'rob  .-bly  faster  subscript  checking 
In  favour  of  1 

(i)  Fore  natural  for  numerical  analysis 

(ii)  Ko  confusion  between  ler  th  and  upper  boun ' of  ar ray 
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Thus  it  might  be  convoy  eut  to  bund  over  an  instant  array  as 
p rameter.  '..e  could  c r:.ote  an  ii  stanl  arra;  set 

thus 

(p,  9,  i-  + 4) 

night  be  an  instant  1-din  integer  array. 

fince  an  instant  array  is  of  1 earth  known  at  co  pile  time,  it 
can  be  set  u_  in  first  level  storm  e. 

Sene  confusion  is  possible  between  literal  an  ■ ir.  stent  arr  ys, 
p'wrK'gs  they  shouldcrly  be  allow  ’d  as  para  eters  wh  n the  c^nfusi  n 
is  li'  ely  to  be  r.in'mal . 

4.1  Tqu' valence 

It  is  pro  osed  that  an  equivalence  feature  lr  introdu  ;ed  wh 
a sequence  of  scalar  vai rabies  nay  be  mapped  onto  anurrey  cf  t.  e 
c type. 

e.f.  int  x y,  i,  j,  k a]  1;  a; 
then  a(4)  would  refer  to  i. 

This  enables  one  to  perform  bloc.,  transfers  of  ercu  s scalars 
and  also  to  change  (e.g.  bj  a conversational  program)  one  of  them 
by  a dynamic  reference  whilst  retaining  legibility/  and  efficiency 
for  norir.rJ  s.  ecific  access. 

This  could  be  extended  to  arrays  thus 

int  array  (;' ) p,  r,  r,  s alias  t; 
then  o(l  ) is  t(2,  1 ) 


5 TYPES 

5.1  Address  variables 


Some  react  t languages  ( ) n r articular  .1,  oi  5s)  •. ; low  t'.:e 
Licit  or.ni  . 1 • L ’ >n  o res:  , i 

variables . The  u: e of  such  vari  . ires  c re  in  a 1 

structur  d languo  e;  U is  :.ly  too  e-  cy  tc  v e d dresses  ul 
scone.  But  nevertheless  : 1 ress  variables  used  correct  . 
consieralle  economies  in  c „ d ing. 


Somethin''  along  t!io  fo'lowir.  lines  is  propot -.d. 


The  concept  of  a type  is  extended  to  allow  the  declaration  of 
v rial  • hose  valu  is  the  ’ other  (i  vari 

The  format  of  the  declaration  . '11  be  i entical  to  the  rx;  re  s ' r. 
of  byn:TiC  parameters  (which  are  address  variable.  ) 


i 
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e.g.  ir.t  nano  p,  w,  r; 

,j3  /‘nr  a.  ;.t  statements  re  concerned  these  v rii 

b-’wve  1 ! e t:  :•  "omal  jnara::.-'  tens  *.lreedy  in  RTL.  Thun  i: 
variable  r:  n !’;.r  1-5  then  the  allowed  form  n the  ' 
the  .-r\nc  ir  currently  allowed  for  an  actual  psiroxetcr  aiw 
use  in  expressions  on  the  RMS  is  as  for  formal  parameter 
This,  of  course,  ; .cans  that  the  actual  formal  correspond* 
parameters  is  : r ly  the  mach  nism  of  assignment.  Th< 
therefore  unili'd. 

Tt  will  he  a.ppr°ci  ted  that  this  need  not  complicate  the 
much,  th  intermediate  codes  all  exist  anyway,  only  phasi 
re  o ganisin.  . 

note  as  a eorollory  that  it  will  n be  possible  to  have 
procedures, 

c.  . int  r-am.e  proo  p( ) ; 

Similarly  .-no  wishes  to  decl  re  mays  with  only  the  fir: 
storage  (as  in  current  formal  parameters)  or  with  dopes  t 
only  p rt  way. 

e.  . int  array  (,)  x; 

could  set  w.  tlr  first  level  storage  only;  x must  be  a 2 
ini,  array  ( 5 , ) y ; 

world  sat  u the  fir.  t level  store  e and  the  1 holes  for 
level  of  am  / storu  e but  not  : ..e  elements  thexselv-B. 


Tote  that  I am.  assuring  fixe-  . lower  bounds  -nd  haw-  r.ovcc 
list  to  before  idcr.ti  'r.-:  - this  simplifies  compilation 

int  array  (5,5)  z; 

would  s't  u all  the  storage  in  the  normal  .ay. 

.••.Iso  e.g.  ir.t  rono  array  ( , p: 

Assigments 

ssiyiincntn  to  array  variables  and  the  values  of  array  vaj 
are  un -mbiyuous  and  pose  no  problems,  however,  in  the  c; 
; cal'.r  variables  there  ire  possible  ty],cs  of  assign  men- 

Eli  moose  ,,c  have  ir.t  r anc  n,  m; 

Tnt  u,  v; 

then  v.e  wish  to  perform 


Ay. 

h » / 
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(i)  c(v) : =c(u) 

(i)  c(c(n)) :=c(u) 

(iiij  c(c(n) j:=c(c(m) ) 

(iv)  c(u):=c(c(n) ) 

(v)  c(n);=u 

(vi)  c(m);-c(n) 


These 

re 

currently 

represented  in  RTL 

0) 

by 

v:=u  and  ] 

parameter  mechanism 

(ii) 

by 

n ; =u 

(iii) 

by 

n:-m 

(iv) 

by 

u:=n 

(v) 

by 

parameter 

mechanism 

(vi) 

by 

parameter 

mechon ism 

and  we  now  wish  to  express  (v)  and  (vi)  in  assignments. 


I suggest  the  assignment  action  be  the  action  across  parameters;  thus 
the  type  of  value  to  be  assigned  is  determiner"  by  the  destination  -.no 
in  order  to  assign  indirectly  we  use  the  o crator  val . The  :h $ is  then 
interpreted  appropriately  so  (following  Algol  63). 


(i) 

v:  ~u 

(ii) 

val  n:=u 

(iii] 

) val  n:=m; 

(iv) 

u : =n ; 

(v) 

n:--u; 

(vi) 

in:=r.; 

Alternatively  one  could  be  quite  specific  and  have 

(i)  v:=u 

(ii)  vain : ~u 
(ii.i)  val  n:=val  m 

(iv)  u:=v-'l.  n 

(v)  n:=ref  u 

(vi)  m:=r. 

The  above  is  very  explicit  a:  d is  a b!t  lii:e  CORAL  in  some  r spects. 
(Loss  chance  of  erros  but  perhaps  a bit  tedious  to  us ej. 


\ 


T 


new  type  of  assignment  (bit 


A third 

dp 

preach  (T 

ad  hoc 

I V 

cel) 

(0  - ( 

iv) 

As  HOT t 

(v) 

n<= 

u 

(vi) 

n 

Eor  exa 

’ v;I 

e of  the 

oxpliei 

4-  r, 

1/  C 

onven lion 

Ty_ ieal 

US 

r'S  of  a . i: 

nr  trix 

al 

ehra  etc. 

e.g.  instead  o'1  a [i,  jj  :=a  £i,  kj  ; 

write  b:=  a ^ ij;  b[jj:  = bQcJ 
(where  array  b has  been  declared). 


Security 


There  are  t,.o  min  problems  (i)  ensuring  that  uninitialised  ad  a res., 
v riables  a -e  nut  used  (we  h ve  ignore  this  I’cblen  in  T • / 1 with 
section  variables)  and  (ii)  ensuring;  that  ad  resses  are  n t urwd 
outside  their  scope. 

Tv/e  solutions  spring  to  :..ind:  (a)  only  allow  address  variables  in 
a 'sv.  stem’  version  of  the  1 <nguage  and  leave  the  risks  to  the 
prow  owner,  or  (b)  restrict  their  use  so  that  invalid  actions  carrot 
result.  Solution  (a)  needs  no  investigating  so  consider  (b). 


Ini t i al i s ati on 

Either  the  variables,  are  automatically  initialised  to  safe  dummies 
or  the  user  must  speciiy  initialisation.  To  do  the  latter  in  a 
deal  ration  will  mean  introducing  inner  blocks  otherwise  the  full 
benefit  of  the  ad.ress  variables  will  not  be  felt.  One  does  not 
wish  he  be  forced  to  initialise  address  variables  tc  a useless  value 
bee:  use  the  u.  ful  value  has  not  ■ et  been  computed.  Gee  also  3.2 

Geo  ing 


I*  ad  rcss  variable  may  be  used  if  its  value  is  cut  of  scope.  The 
simplest  wap-  of  preventing  t.is  is  to  ensure  that  the  value  of  an 


ac  rest  vfU’ieble  i.  in  see  e whenever  the  vri  ble  itself 
tills  ir.plcs  that  assignments  must  be  restricted  to  passing 
b’v.'cen  variables  in  the  same  block  or  from  an  outer  : lock 


ad  res 
to  an 


cz 


:‘n  or  one. 


One  conseru  nee  of  this  is  that  ;m  ad'ress  variable  in  a data  set 
c:n  only  rc  er  to  variables  in  that  a ' a set. 


5.2 
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Prccodcntsf  AlL,ol  62,  C RAL  66,  TPL 
' 'Lxod  noint  arithmetic 


'•’he  current  version  of  RTL  and  SI.IL3  have  facilities  for  scaled 
fixed  point  ar  ithmetic.  To  my  inowl'  are  these  have  never  been 
used;  one  serious  attempt  was  made  but  lack  of  ki.owlc-d.  o of  ranw  s 
or  intermediate  values  caused  us  to  resort  to  real  arithmetic. 


The  facilities  provided  by  die  compiler  in  this  area  arc  ■ oly 
a convenience,  it  is  possible  to  use  integer  arithmetic  and  -.erfera 
th.c  : ealing  ones’ 1'"  - t is  is  easy  because  h L allows  shift  opo«-.  ti'c.r. 
It  Is  therefore  _.ro-«e;  cd  -o  del  ote  scaled  integers.  This  would  rr  ■ ily 
simplify  the  compiler. 


T e direction  of  a shift  is  often  known  but  its  size  is  n t.  ..t  the 
moment  there  is  no  way  of  informing  tic-  cos.  lor  of  the  direction 
alone.  The  addition  of  operations  SBLk,  ..i.  S'  7.L,  SILL  Is  proposed, 

5.3  Boolcans 

Boolean  variables  and  values  in  the  true  Algol  sense  are  elegant 
but  can  Ic'd  to  inefficiencies  in  com  onl  occurring  circumstances 
u .less  a complex  (and  therefore  unreliable) compiler  can  bo  used. 

bus  in  RTL/l  clauses  like 

if  s = 1 or_  s - 2 then 

are  poorly  compiled, 

A convenient  method  of  overcoming  this  is  to  delete  the  concept 
of  a Boolean  ty;  c from  the  language  and  introduce  instead  the 
"condition"  used  in  an  if  chuse.  Logical  open  tions  on  int-  -ers 
considered  as  bit  pattern  .ould  remain. 

Tims  it  is  proposed  that  a structure  similar  to  that  of  COAL  bo 
adopted. 

The  operations  and , or  ^ — ^ would  only  be  used 

within  conditions  and  a condition  would  be  evaluated  ’’rom  left  tie 
right  only  as  far  as  is  necessary  to  determine  the  result. 

Logical  operations  o'-vivalent  to  end  or  and  not  for  integer  variable: 
would  -also  be  available  but  with  a di  ,'errr.t  not  tion  to  - void 
confusion.  The  actual  i ;mes  chosen  for  CORAL  (d iffer  uu 'or.,  mask), 
ore  not  ur.ivers ally  liked,  and  altorir. live  suggestions  would  be  wclcorr . 


Precedent:  CCRAL  66,  POP-2 
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5 A General  Typos 

There  are  tines  when  conventional  t pe  dependent  high  level  langu  gs 
co  no  hove  the  reouired  flexibility.  Uote  our  own  diff ic.  lties 
• ' th  l/0.S:X3  had  'o  resort  to  special  statements  for  this  purj.ose. 

In  order  to  overcome  these  difficulties  in  a general  and  legal  manner 
the  general  type  is  proposed.  variable  f type  general  can  contain 

ary  value  nlu3  a flay  indicating  the  ty  e of  the  value.  Thus  it  is 
likely  to  be  moderately  inefficient.  Operation  will  also  be  needed 
to  identify  the  type  of  the  value,  having  identified  the  ype  of  a 
value  one  will  probably  wish  to  transfer  the  value  to  a variable  of 
the  a propr!  ■.  te  type.  This  can  bo  conveniently  performed  by  the 
"conforms  to  and  1 ccbmes"  of  Algol  6r  . 

Thus  supposin’-  we  have  a procedure  with  one  parameter  v.a  ' cli  coul  d be 
on  integer  value  or  a one  dimensional  real  array.  The  coding  ml  ht 
be  as  follows: 


proc  p (gen  x ) ; 

begin  Int  i;  real  array  ()  a: 

if  i: :=x  then  action  if  Integer  else 
if  a: :-x  then  action  if  array  else 
fail  ... 


the  clause 

i:  : -x 

/ 

has  value  true  if  the  types  are  compatible  and  in  this  event  the 
va"  ue  is  transferred. 


Koto  that  : : = unfortunate 1 
a rota  symbol;  Algol  6C's 
is  sought.  =••&:=  or  =;-  h 

It  would  probably  be  best 


y already  has  an  established  mesnin  as 
choice  is  thus  not  liked  and  :n  alternative 
nvc  been  suggested. 

to  allow  no  operations  on  general  v r 1 'lies 


other  than  the  above  and  assignment. 


Using  genera]  variables  and  instant  arrays  it  would  be  relatively 
easy  to  provide  arbitrary  record  type  i/O  litre  f.‘!L3  or  Ft  Tibi!.'. 

e.g.  proc  write  ( en  -array  ()a); 
begin  . . . end 

used  thus  write  (('answer  is',  x,  2,  0)) 


BESLAVAlii:  :.t  t-ji  / 


FOR  STATEMENTS 

It  in  proponed  that  a style  of  statement  similar  to  Algol  62  and 
H/1  bo  adopte  d The  iV  1 statement  is 

for  i:=  a dp  b _to  c while  d do  S; 

The  effect  is  to  iterate  as  usual  with  the  additional  priviso 
t..vt  d must  be  true.  The  iteration  is  terminated  by  either  the 
count  reaching  or  passing  the  limit,  by  u beconing  false  or  by 
jump  in-;  out. 

The  control  variable  is  a variable  local  to  the  loop  an  . in 
read  only.  Tills  rives  the  compiler  better  opportunities  for 
optimisation. 

Various  parts  of  the  statement  can  be  omitted. 

by  1 if  the  step  is  1 
while  d if  d is  always  true 

to  c if  the  loop  is  to  be  terminated  by  the  v;h  le 
or  ju  .ping  out. 

e.g.  for  i:=  1 _to  10  do  ... 

for  i : = 1 by  1 wh  ' lc  p(i)  q ( 1 ) do  . . . 

The  w ole  of  the  iterative  part  can  be  discarded  thus 

wh  11  e check  (:•;)  jlo  ... 

Finally  'if  the  control  variable  is  not  used  in  the  statement 
(as  e.g.  in  the  ?.Tl/l  statement) 

for  j.:=  1 sten  1 until  IOC1  do  nev/l'ne  (); 

this  can  be  contracted  to 

to  100  do  newline ( ) ; 

(or  would  you  prefer  for  ICO  tines  bo  nev/1  ine  ( ) ; ) 

lie  omission  of  the  control  variable  when  not  used  will  make 
possible  the  rapid  compilation  of  better  codin  in  "there  cases. 

< 

Precedents:  PL/l , Algol  68 
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7 S '.7TCK3S 

Switches  hr. vc  proved,  to  bn  somewhat  anonolous  in  behaviour  and 
-in  fact  there  is  currently  a restriction  pre.-nting  the  - r lire  non 
locally.  The  inability  to  declare  snitches  within  for  statements 
coupled  with  the  rule  that  one  ray  not  jump  into  for  statements 
has  meant  that  programming  h.  s not  always  been  as  transparent  as 
desirable. 

A solution  is  to  have  a switch  statement  rather  than  a switch 
de c larat ion.  c.g. 

goto  case  i of  LI , L2 , L3  else  ....  ; 

Preccndent  FORTRAK,  Algol  66,  Algol  68 

N B:  An  alternative  nomenclature  could  be  considered 

e.g.  execute  i of  .... 
branch 
select 
switch 


8 :‘:.V7Ac:  :rr?r  an  ;u 1 rirs 


Following  P Naur  it  is  proposed  tha  • some  information  about  the 
object  machines  characteristics  bo  made  available  to  the  pro  rrrer 


i 

i 


in tbit  number  of  bits  in  -'ntoger  representation 

in tbytes  number  of  bytes  which  can  be  stored  in  the 

same  space  as  .ir  integer 

r~alby  es  number  of  byt  s which  can  be  stored  in  the 
same  space  a.  a real 

wordby tes  number  of  bytes  which  can  be  stored  in  the 
same  spac^'  as  a reference 

The  above  arc  effectively  macros 

.Also  the  procedure  (supervisor  call?) 

x);t..rcc  staci:free() 
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9 ' l)ArA  SAV  INIAI/JJFAA’IOi: 

This  could  be  optimal  or  mandatory  with  default  values, 
i'or  scalars  it  is  proposed  that  the  declarations  be  thus 
int  x:=3,  y :=7; 

Por  arrays  thus 

int  -.rray  (3)  p :=  (l,  2,  3),  q:=  (4,  5,  6); 

and  the  upper  bound  nay  optionally  he  replaced  by  an  asterisk  when 
the  value  can  be  obtained  from  tiie  initial  list. 

In  particular  it  must  be  omitted  if  v.e  allow  non  rectangular  arrays 
thus 

int  array  (»,<■)  t:  = ^(1,2,  3),  (l , 2),  (l)) 
and  a typical  example  might  be  an  array  of  messages 

byte  array  (7^*)  days:=  (’  Sunday 1 , 1 monccy’ ... ) 
where  the  individual  messages  are  of  different  lengths. 


I 

f 


jgpb/jp 

3 11  70 


♦•a** 


f r 


A1  Address  variables 

Th's  example  : llur.tratos 

(i)  IIov;  a ty.  leal  procedure  looks  in  RT:/l 

(ii)  How  it  mip:ht  lock  transliterated  into  RTl/2 

(iii)  The  use  of  address  variables  in  RT'l/2  to  avoid  unnecessary 
subscript  evaluations  and  thereby  speed  inner  loops 


R T L 1 


ZPROCEDURE  INVERT ( %REAL  ZARRA Y 2 A;  %REAL  ZARRAY  BJ  ZVALUE  % INTEGER  N); 
ZBEG  IN  % I NT  EGER  hJ,KJ 
%REAL  S>Ci 

%FOR  J!  =1  % STEP  1 ZUNT I L N-l  ZDO 
%BEG I N C:=0; 

%FOR  I : = J %STEP  1 ZUNTIL  N ZDO 
ZBEGIN  ZIP  ABSCAC 1, J3 )>C  ZTHEN 

ZBEGIN  C:=AES(AC I, JD );  K:=l  ZEND 

ZEND  J 

l S:=BCK3;  BCK3:=BCJ3;  bcjd:=s; 

ZFOR  I : = J ZSTEP  1 ZUNTIL  N ZDO 

ZBEGIN  S:=ACK,I3;  A C K, 1 ] : =A C J* ID l ACJ,I3:=S  ZEND J 
ACU> J3:=l /AC JD; 

ZFOR  I : = U + 1 ZSTEP  1 ZUNTIL  N ZDO 
ZBEGIN  S: =AC I , J3*AC Jj J33 
BC I 3: =BC I 3-S*BC JDJ 
ZFOR  K : = «J  + 1 ZSTEP  1 ZUNTIL  N ZDO 
AC I,K3:=AC I , K D -S*A C J,  K D 

ZEND 

4 ZEND; 

ecnd:=bcnd/acn,nd; 

5 ZFOR  I : =N-1  ZSTEP  -1  ZUNTIL  1 ZDO 

ZBEGIN  ZFOR  U:=I+1  ZSTEP  1 ZUNTIL  N ZDO  B C I D : =BC I D -B C J D *A C 1 , J D J 
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PHOC  INVERT  (HEAL  ARRAY  ( > ) A>  REAL  ARRAYO  B>; 

BEGIN  I NT  K.NJ 
REAL  S*C; 

N : =LENGTH  BJ 
FOR  J TO  N-l  DO 
BEGIN  C:=0i 

FOR  I S = J TO  N DO 

BEGIN  IF  ABS(A( I> J) >>C  THEN 

BEGIN  C:=ABS(A(I,J>>;  K:=I  END 

end; 

SJ=B(K>;  B(K):=BCJ);  BCJ):=S; 

FOR  I : =J  TO  N DO 

BEGIN  S:=A(K,I>;  A <K>  I > : =A  < J,  I > ; A(J>I):=S  END; 
A( J, J):=l /A ( J ) ; 

FOR  I : =J+1  TO  N DO 
BEGIN  S:=A(I>J)*A(J*iJ); 

B( I ) : =B ( I ) -S*B( J ) ; 

FOR  K: =J+1  TO  N DO  A ( I ,K > : =A ( I >-S*A < J,K > 

END 

end; 

B(N):=B(N)/A(N,N); 

FOR  I : =N-1  BY  -1  TO  1 DO 

BEGIN  FOR  J: = I + 1 TO  N DO  B < I > ! =B< I > -B( J >*A < I , J > ; 

B(  I ) : =B( I ) *A ( 1*1) 

END 

END 


NOTE  (i)  Absence  of  and  shorter  forms  of  reserved  v;ords 

(ii)  Abbreviated  for  statements 


(iii)  Third  parameter  omitted  since  length  can  be  obtained  from 
length  operator 

(iv)  Square  brackets  replaced  by  round 


(v)  i and  j declared  by  occurance  as  control  variables  of 
for  statements. 


•V*.***.  * --•  v 


Ik 
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RYl/2  with  address  vhls 


,s 


l 


i 

t 

! 


■ 

4 


r * 

[ ; 
f * 
i 


PROC  INVERKREAL  ARRAY  ( .*  > A * REAL  ARRAYO  B); 

BEGIN  INT  K.NJ 
REAL  S,C; 

N:=LENGTH  BJ 

FOR  J TO  N-l  DO 

BEGIN  REAL  ARRAYO  AJ:=A(J); 

REF  REAL  BJ:=REF  B(J>,  AJJ:=REF  A(J*J>; 

C:  =0  ; 

FOR  I!=J  TO  N DO 

BEGIN  IF  ABS (A  ( I j J > ) >C  THEN 

BEGIN  C: =AES(AC I> J)  );  KS=I  END 

end; 

S: =B(K  >;  B(K):=VAL  Bj;  VAL  BJ:=S; 

FOR  I : =J  TO  N DO 

BEGIN  S:=ACK,I>;  A ( K, I ) : =A J ( I ) ; AJ(I):=S  END; 
VAL  AGO: =1 /VAL  AJJ; 

FOR  I: =J+1  TO  N DO 

BEGIN  REAL  ARRAYO  AI:=ACI>; 

S:=AI(J)*VAL  AJj; 

B< I ):=B( I ) -S*VAL  bj; 

FOR  K:=J+1  TO  N DO  A I (K > : =A I C K> -S*A J ( K ) 

END 

end; 

B(N):=E(N)/A(N,N>; 

FOR  I : =N-1  BY  -1  TO  1 DO 
BEGIN  REF  REAL  B I : =REF  B(I); 

REAL  ARRAYO  A I : =A ( I ) ; 

FOR  J:=I+1  TO  N DO  VAL  BI:=VAL  B I -B < J >*A I C J ) ; 
VAL  B I : = VA L BI*AI ( I ) 

END 

END 


( 


■ 


r 


\ ; 

t : 
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A2  i'csted  procedures 

A.  example  of  d levels 


t si:  a; 
be  in 


i roc  b 
be;  in 


r^OC  p( ) ; 

be  In. 


i-oto  L 


"nd ; 


L: 

end; 

b(.«..); 

b ; 

t( ); 


m transfer 
< fail>  ; yoto  II 


(l)  b is  r.  procedure  .rich  does  some  for::,  of  l/C  and  incr 
error  recovery  by  reissuing  the  rejur.t  if  it  A-.  ils. 
b has  been  made  into  a procedure  because  it  is  v.is  ei 
use  it  r.any  times. 

(ii)  transfer  is  an  r ternal  procedure  v.ich  performs  ti  e 
usin_  a parameter less  procedure  to  per  'or-.,  stro  in  . 
The  actual  proce-.  re  used  is  p. 

- reust  or bedded  vrithin  b since  p detects  the  error 
v/ishes  to  transfer  control  to  the  label  I.  In  b 1-  th.' 


rpor- tee 
L tO 

I/O 

cr.d 

s event 
ba 

out] ire  . 
:ro  to (_2r 


It  ’.;o.  '10  be  of  £jr*\:t  value  to  un  if  you  could  spare  .the  ti:.r‘ 
to  co.  pie  to  the  enclosed  »uc  tionn-aire  '-rid  re  turn  it  to: 


J G P Barnes 
RTL  Project 

Imperial  Gnome  ■ 1 Indus  trier  Linite  . 

Central  Inrtrumor  t ;"E  - roll  Laboratory 

Bozo Gown  ..Pur.  3 

7.1  > Ltchurch  Hill 

ItH  I-r:G  AG8  7PF 

Berk  s 

England 


Further  copies  of  the  quo. tionnnire  - re  available  on  reouest. 


- • — • •-  •% - m 


qiassTiorc'Ai  ''  0..  <ti/2 


■o  ."or.rlote  or  delete  (*)  3r  a;  p.~oi;riate.  The  i. umbers  a .i-cent  to 
•-.u  vtions  refer  to  the  relevant  paragraph  in  the  main  Gocuont. 


Id  PJ-l/2:  *(As  a uor  of  ' l./l 

(An  a p otential  user  of  Rrj'l/£ 
(General 


ail/1  text  is  not  very  legible  * agree/di eagre e 

S acre  brackets  should  be  replaced  by  round  !:'ag,rec/di.v  > ree 

" prefer  reserved  words 
( p BEGIN  etc 

Bearing;  in  nine  the  characters  available  - 

I prefer  *(  different  sg  rbols)  for  opening  and  closing  quotes 
( same  symbols  ) 

?'e  or  !-: chav/by te 


low  many  levels  .f  nestis  are necessary 


Inner  blocfs  *v;o.:ld/'..o  Id  not  be  as  • f ul 

I ..ree  th  t value  is  confusing  *Yes/l.c 

I greyer  A.-.:-f7rn sc 

I prefer  as  it  is  now 

T r ggf'.~t  as  :-lterrs  tive  -.ora  for  HlVUIiK 

•:icb  of  the  folio. .ing:  statements  best  expresses  your  attitu  *o  to 
f-'.-'c’  lower  bounds? 

*a/h/ c 

( u.)  .idle. Ions  not  to  allow  them  to  vary  despite  ineff icionc'  s 
that  mi  };t  '-rise; 


JLiu>Lc 


j 


tv  *P»  . ♦»***•  — ’ . < 
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uestlonn.tirr  oontd. 

(b  J Cl  . ov;.  \t  regre  c not  .ilov.  r..  v able  lo..cr  bo.  nas  ’■  :t  * • <■ 
igor  s o].,  -..or ill  h 11  o; 

(u;  rays  ’el t tint  lo.;or  bounds  nbo  Id  bo  •jy.-..]  ■ t 

the  lo./or  bound  it  oulb  b *0/l 

4.’  L ' t r 1 • :y;;  * .'oul-'/ v;oul  d.  i.o  l be  useful 

4.5  Tn.  rr  yr  ; . ould/.vould  iit  bo  useful 

rv.'i:./  xi  not  confuse  by  liter':  • .d  ins  >.  arrays 

4.4  So'  o sort  • " f puivulence  feature  is  desirable.  Do  you  think 
tnat  the  propos  1 described  rot's  far  enough?  :Yes/Uo 

5.1  I "ayrcc/ disagree  that  address  variables  arc  neccssry 

V’liich  of  the  ty  . es  of  assignment  do  you  prefer? 

*(  (i)  sc::ev;h  .t  ike  Yl.-ol  68 
( iii)  the  explicit  form 
( (iii)  tb.e  ad  hoc  extension 

The  restrictions  n the  use  of  address v .riables  to  ensure  s canity 
mi  ht  be  suer,  as  to  make  then  useless  in  some  areas. 


"Agree/ dir. : 


f 5 ‘ TC.  C 


f you  ree  dr  you  think  that  a s/ste..  version  of  the  language  in 
’.;hich  restrictions  re  relaxed  is  sensible?  *Ycs/ko. 

5.2  I thin!:  that  scaled  fixed  point  variables  are 


*(  useless  in  practise 
( possibly  useful 
(essential 

Directed  shift  operations  "would/would  not  be  useful 

5.5  .."hi oh  of  the  foblov.ing  best  expresses  your  attitude  to  Pool  an  types 

*a/b/ c 

(a)  I thin.  P.Ti/l  is  C K 

(b)  Boolean  types  should  be  retained  but  tae  definition  of  the 
method  of  evaluation  of  boolean  expressions  shou.d  be  dunged 
to  specify  left  to  right  evalu  ition  only  as  far  as  is  r.rc --scary 

(c)  the  proposals  to  delete  Booleans  and  institute  conditions 
instead  is  preferred. 


— ■ ■■■'■  ■■■■- 


— 
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fu  : t loruw  in  conta 


(•Mi'll  variables  :'do/do  not  sees  necessary. 

I propose  tie  alternative  symbol  to  : :=  for  the  ’conforms  to 
and  becomes ’ opera i.ion 

In  ysacral  I *li  e/dislise  t):e  proposals  for  for- statements 

7 n.:~  ''cr  :(  to  100  £o  ) to  denote  repetition 

( for  100  tines  do) 

I pro  'or  (s. .-itches  as  they  a-e  in  I'i'l/l 
(the  case  statement  proposed 

I sup,;:  . t the  follov.ine  alternative  nomenclature 

I -.vich  to  have  the  following  available  to  me  * /intbits/  intbytes/ 

real  by  ter/'.vordby  tes . 

T \:o  Id  also  lli.ee 

T p re  far  ::,o_  lion  J/iNMdatory  initial  i sat  ion 

If  yc»  pro; 'or  optional  in i tia J isa Lon  sho  Id  there  nevertheless  be 
a default  value?  '‘YSS/l'O 
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PEARL*) 

The  Concept  of  a Process-  and  Experiment-oriented  Programming  Language 

J.  Brandes1),  S.  Eichentopf2),  P.  Elzer3),  L.  Frevert4), 
V.  Haase'),  H.  Mittendorf5),  G.  Muller6),  P.  Rieder6) 


Summary:  The  main  features  of  a programming  language  for  on- line -control  of  industrial  processes  and  scientific 
experiments  are  described.  Mainly  discussed  are  ihe  connections  between  the  program  and  the  process  environment, 
the  management  of  storage  space  and  parallel  activities,  the  synchronization  of  tasks,  and  the  non-standard  input- 
output.  The  paper  describes  structure  and  semantics  of  the  language,  but  does  not  yet  give  an  exact  and  definitive 
syntax. 

Zusammenf  assung:  Dieses  Konzept  beschreibt  die  wesent  lichen  Eigenschaften  einer  Programmiersprache  der 
M ittelebene  fur  Anwendungen  in  der  industriellen  Prozefisteuerung  und  in  der  Experimentiertechnik.  Es  werden  haupt- 
sachlich  die  Verkopplung  des  Programms  mit  der  Prozeflum welt,  die  Speicherverwaltung,  die  Steuerung  und  Synchroni- 
ser mg  der  Parallelarbeit  und  nicht  standardmSBige  Ein-/Ausgabem5glichkeiten  beschrieben.  Der  vorliegende  Bericht 
beschreibt  Struktur  und  Semantik  der  Sprache,  nicht  aber  eine  exakte  Syntax,  die  nochvon  der  "PEARL  Arbeitsgruppe 
erarbeitet  werden  wird. 


1. Introduction 

In  recent  years  it  has  been  realized  by  many  people  that 
higher  level  programming  languages  like  those  for  com- 
mercial or  scientific  applications  will  be  advantageous 
and  even  necessary  also  in  the  fields  of  process  and 
experiment  automation  [1,2,3],  Some  proposals,  such 
as  RTL  [4  | or  an  extension  of  PL/1  [5]  also  proved  the 
fundamental  possibility  of  expressing  specific  charac- 
i i istics  of  process  and  experiment  programs  by  a higher 
level  programming  language. 

The  possibility  of  implementation  had  been  doubted  for 
quite  a long  time;  however,  it  has  been  demonstrated 
meanwhile  by  the  existence  of  some  solution  applicable 
to  partial  fields  [6,7]. 


1.1.  Fundamentals  of  the  PEARL"  Concept 

"PEARL"  is  a compilable  programming  language  of  the 
intermediate  level,  such  as  ALGOL  or  PL/1,  since  this 
type  of  language  offers  maximum  flexibility  in  addition 
to  easy  handling  and  learnability.  Since  a relatively  large 
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be  able  to  treat  also  more  complex  problems,  It  Is 

intended  to  define  self-contained,  fully  upward  compatible 
subsets  for  smaller  computing  systems.  A brief  sum- 
mary is  given  of  both  the  main  features  of  a program  for 
process  applications,  which  practically  prevent  its  being 
written  in  a conventional  programming  language 
(FORTRAN,  ALGOL  60,  COBOL,  etc.),  and  means  of  so- 
lution proposed  by  the  "PEARL"  concept. 

1.1.1.  Machine  Dependence 

In  a computer  program  for  process  application  also  the 
entire  peripheral  equipment  must  be  described  and 
selected  which,  in  most  cases,  may  lie  of  non-standard 
design  and  more  diversified  than  in  commercial  or 
scientific  applications  of  electronic  data  processing.  Due 
to  the  improbability  of  standardizing  all  possible  hard- 
ware configurations  and  describing  them  uniformly  at 
the  level  of  an  advanced  programming  language,  a 
PEARL"  program  is  subdivided  in  principle  into  a sy- 
stem dependent  part,  the  system  division,  and  the 
problem  division  which  is  largely  independent  of 
the  system.  The  system  division  provides  the  link 
between  the  process  peripheral  equipment  and  the  pro- 
gram, whilst  the  problem  division  constitutes  the 
control  or  measuring  program  proper.  Thus,  only  the 
system  division  has  to  be  modified  when  passing 
from  one  type  of  computer  to  another  (Chapter  3.). 

1.1.2.  Parallel  Activities 

Usually  a process  program  during  operation  splits  up 
into  a varying  number  of  parallel  "tasks"  [8j  some  of 
which  are  performed  completely  independent  of  each 
other  while  others  are  correlated  to  each  other,  i.  e., 
they  have  to  be  synchronized.  The  "task"  is  considered 
to  be  dynamical,  i.e.,  it  consists  in  the  successive  pro- 
cessing of  one  or  several  pieces  of  code.  The  process 
program  is  characterized  by  the  interaction  between  the 
tasks  which  is  made  possible  by  synchronization  with 
the  help  of  semaphores  [S]  (Chapter  4. 1.-4. 4.). 

1.1.3.  Running  Time  and  Storage  Management 

In  a "normal"  computer  program,  the  aggregate  compu- 
ting time  in  principle  does  not  matter.  It  is  sufficient 
that  the  program  will  be  terminated  within  a period  of 
time  reasonable  for  the  user.  However,  since  a process 
program,  in  most  cases,  must  meet  preset  reaction 
times  which,  in  the  most  extreme  cases,  may  be  of  the 
order  of  a few  cycle  periods  (e.  g.,  application  in  nuclear 
physics  experiments)  the  programmer  must  have  more 
influence  on  the  object  code  than  he  has  in  conventional 
programming  languages. 

A related  problem  is  the  management  of  storage  allo- 
cation. Since  often  parts  of  the  program  code  will  be 
stored  on  some  backing  storage  medium,  the  time  for 
loading  the  code  must  be  included  into  the  running  time 
of  a task.  The  programmer  must  have  the  possibility  to 
act  on  the  time  of  loading  as  well  as  on  the  size  of  the 
code  piec  es  to  be  loaded,  though  the  working  storage 
allocation  shall  be  automated  as  far  as  possible 
(Chapter  4.5.). 

1.1.4.  Input/Output 

In  process  programs  there  must  be  much  more  possi- 
bilities of  input  and  output  than  in  programs  for  conuner- 
ccal,  scientific,  nr  technical  applications. 


which  will  allow  the  handling  of  nearly  all  the  input  and 

output  operations  encountered  in  process  technique  under 
uniform  aspects  (Chapter  5.). 

1.1.5.  Types  ol  Data  and  Language  Features 

In  this  respect,  the  familiar  programming  languages 
(ALGOL  60  and  FORTRAN)  prove  to  be  unsufficient. 
Therefore  it  became  necessary  to  include  in  the  language 
more  complex  types  of  data,  such  as  lists  or  structures. 
It  has  been  attempted  to  combine  all  the  elements  of 
modern  programming  languages  which  are  required  for 
process  purposes  (PL/1,  ALGOL  68),  but  to  eliminate 
too  expensive  and  rarely  used  types  and,  if  necessary, 
replace  them  by  new  elements  [10,11]  (Chapter  2.). 

1.1.6.  Relations  to  the  Operating  System 

A programming  language  allowing  interventions  into 
functions  of  the  operating  system  necessitates  also  a 
certain  standardization  of  the  properties  of  the  opera- 
ting system,  e.g.,  uniform  treatment  of  the  interrupts. 

To  obtain  efficiency  and  satisfactory  compatibility  ol 
process  computing  programs  in  a higher  level  program- 
ming language,  the  definition  of  certain  minimum 
requirements  will  lie  needed  which  must  be  met  by  an 
operating  system  for  a process  computer. 

1.2.  Mode  of  Description 

It  has  intentionally  been  avoided  in  this  concept  to  pro- 
pose an  exact  syntax  of  "PEARL".  In  exceptional  casco 
where  this  is  done,  however,  the  usual  notation  of  PL  ! 
is  adopted  jl2). 


2.  Basic  Language 

2.1.  Fundamentals  • 

2.1.1.  Character  Set 

The  character  set  consists  of  approx.  60  characters  in- 
cluding the  latin  alphabet,  the  decimal  digits  and  certain 
special  characters  which  are  in  common  use. 


2.1.2.  Delimiters 

Delimiters  consist  either  of  sequences  of  n(n  1)  special 
characters  (except  blanks),  or  ol  sequences  of  m (m  2) 
letters  (keywords).  How  or  whether  keywords  are  to  be 
reserved,  i.e.  identical  identifiers  will  have  to  be  for- 
bidden, depends  on  the  exact  definition  of  the  language 
structure  and,  therefore,  cannot  be  decided  now. 

2.1.3.  Comments 

A comment,  may  be  placed  at  every  location  in  a pro- 
gram where  a blank  mav  be  written : this  comment  will 
be  enclosed  by  special  characters  as  in  PL/I. 

2.1.4.  Block  Structure  and  Procedures 

The  language  has  a block  structure  similar  to  that  of 
ALGOL  60  and  PL/I  with  its  consequences,  especially 
regarding  the  scope  of  declarations. 

Procedures  will  be  treated  similarly  to  those  in  ALGOL  60 ; 
to  simplify  matteis,  however,  ceridin  restrictions  must 
be  observed,  e.  g.  regarding  call  by  name  of  parameters. 
All  formal  parameters  must  be  specified  (as  in 
ALGOL  60).  [13  f. 
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2.1.5.  Identifiers  ;uid  Declarations 

Identifiers  are  sequences  of  alphanumeric  characters  in 
which  the  first  character  is  a letter.  Identifiers,  in  ge- 
neral, refer  to  data  (values)  of  a certain  type  (variables). 

All  identifiers  used  must  be  declared  in  the  program; 
the  scope  of  the  declaration  is  the  block  in  which  the 
declaration  is  contained.  Identifiers  can  also  be  decla- 
red, in  certain  cases,  in  the  system  division  (see  3.), 
where  the  scope  of  the  declaration  is  the  entire  pro- 
gram. Initialization  of  identifiers  in  declarations  is 
possible. 

Declarations  not  necessarily  stand  at  the  beginning  of  a 
block.  If,  however,  an  identifier  is  to  be  initialized  in  its 
declaration,  this  initialization  must  be  dynamically  exe- 
cuted before  the  identifier  is  used  for  the  first  time. 

Besides  identifier  declarations,  there  are  also  type  de- 
clarations (see  2. 2. 2. 2.)  and  operator  declarations 
(see  2.3.2.). 

2.2.  Types 

There  are  certain  basic  types  from  which,  according  to 
specific  rules,  compound  types  can  be  formed. 

2.2.1.  Basic  Types 

Basic  types  are  INTEGER  and  R EAL  of  different  precision, 
RINA  I,  (bit  string)  of  different  length,  STRING  (character 
string)  of  different  length,  SEMA,  FILE  and  ADDRESS. 

A type  BOOLEAN  or  LOGICAL  is  not  required,  as  it  can 
be  represented  with  BINAL  of  length  1. 

The  declaration  symbols  and  the  forms  of  constants  will 
be  decribed  in  the  following  sections. 

2.2. 1.1.  INTEGER  and  REAL 

Declaration  symbols:  INTEGER (n)  and  REAL(n)  where 
n is  the  minimum  number  of  decimal  digits  to  be  compri- 
sed within  the  mantissa.  If  (n)  is  missing,  an  imple- 
mentation-dependent stadard  length  or  precision  will  be 
assumend.  By  writing  REAL(n),  the  next  implemented 
mantissa  length,  which  is  not  less  thail(n),  will  be  taken. 

Constants  of  the  type  INTEGER  will  be  specified  as  a 
sequence  of  n (n  1)  consecutive  decimal  digits.  Con- 
stants of  the  type  REAL  will  be  specified,  similarly  to 
PL/I,  as  decimal  constants  which  are  not  integer  con- 
stants. Blanks  within  one  number  are  not  permitted.  The 
internally  used  mantissa  length  is  the  next  implemented 
one  which  is  not  smaller  than  the  number  of  digits  in  the 
constant. 

2. 2.1. 2.  BINAL 

Declaration  symbol:  BINAL(n)  where (n)  is  the  number 
of  bits.  If  (n)  is  missing,  an  implementation-dependent 
standard  length  will  be  taken. 

In  arrays  and  structures  BINALs  will  be  closely  packed 
within  limits  of  the  effective  addressability,  in  order  to 
save  storage  capacity.  For  BINALs  not  in  arrays  and 
structures,  the  next  implemented  bit  string  length,  not 
less  than  (n),  will  be  taken. 

Constants  of  the  type  BINAL  can  also  be  specified  in 
octal  notation  with  the  digits  0 to  7,  and  in  sedecimal 
notation  with  the  digits  0 to  9,  and  the  letters  A to  F. 

Fxample:  'll 01 001 01 01  I B binary 
’6453'0  octal 
'D2B'S  sedecimal 
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The  notation  of  the  BINAL  constants  is  not  as  yet 
finalized. 

2. 2. 1.3.  STRING 

Declaration  symbol:  STRING  (n) 
where  (n)  is  the  maximum  number  of 
characters  contained  in  a string. 

STRING  constants  will  be  enclosed  in  apostrophies. 
Example:  'ANTON +BERTA’ 

2. 2. 1.4.  SEMA 
Declaration  symbol:  SEMA 

A variable  of  the  type  SEMA  can  only  assume  integer 
values  and  is  used  to  synchronize  tasks  (see  4.4.). 

2. 2.1. 5.  FILE 

Declaration  symbol:  -[ SEQUENTIALIRANDOM}  FILE 

(unit  identifier,  pages/file,  lines/ 
page,  characters/line) 

FILE  identifiers  occur  as  parameters  in  1/0  procedures. 
There  are  two  types  of  FILEs,  the  SEQUENTIAL  FILE 
in  which  only  sequential  reading  and  writing  is  possible 
and  the  randomly  addressable  RANDOM  FILE. 

FILE  specifies  data  organized  in  pages,  lines  and  cha- 
racters and  stored  on  external  storage  [11].  The  decla- 
ration contains,  therefore,  the  name  of  the  unit  (e.  g. 
drum,  disc),  the  number  of  pages  per  file,  lines  per 
page  and  characters  per  line. 

2. 2. 1.6.  ADDRESS 
Declaration  symbol:  ADDRESS 

Variables  of  the  type  ADDRESS  have  as  values  ADDRESS 
constants,  i.  e.  identifiers  (also  subscripted)  of  variables 
which  must  not  be  of  the  type  ADDRESS. 

There  are  three  address  levels : 

Level  2:  ADDRESS  variable,  i.  e.  identifiers  which  indi- 
cate values  of  the  type  ADDRESS; 

i 

Level  1 : ADDRESS  constants,  i. e.  identifiers  which  indi- 
cate values  excluding  those  of  type  ADDRESS; 

i 

Level  0 : Values  which  are  not  of  the  type  ADDRESS. 

The  following  addressing  mode  is  used  for  assignment : 

The  left  side  of  an  assignment,  i.  e.  the  side  to  which  the 
right  side  is  assigned,  must  be  on  level  1 or  2 of  the 
address  levels  mentioned  above.  The  level  of  the  right 
side  of  an  assignment,  i.e.  the  side  which  will  be  assigned, 
must  come  directly  under  the  level  of  the  left  side. 

Hence : 


Left  side 

Right  side 

Level  2 
Level  1 

Level  1 
Level  0 

Accordingly,  the  level  of  the  right  side  will  be  automati- 
cally adjusted  to  the  specified  level  of  the  left  side,  as 
far  as  this  is  possible. 

Example  : 

REAL  A,  B; 

ADDRESS  POINTER  1,  POINTER  2; 


\ 


ilh. 


A :=  5.7 


Examples:  1)  Call  of  the  entire  serond  column  of  the 

matrix  declared  above : 


• LEFT:  LEVEL  1;  RIGHT:  LEVEL  0;  CLEAR.*/; 

B :=  A 

/*  LEFT:  LEVEL  1 ; 

RIGHT:  NEXT  ALSO  LEVEL  1,  AFTER  ADJUST- 
MENT TO  LEFT  SIDE  LEVJ2L  0,  I.  E.  THE  VALUE 
(HERE  5.7),  INDICATED  BY  A,  WILL  BE 
ASSIGNED  TO  B.  */ ; 

POINTER  1 : - A 

/*  LEFT:  LEVEL  2; 

RIGHT:  LEVEL  1; 

THE  ADDRESS-VARIABLE  POINTER  1 ASSUMES 
IDENTIFIER  A AS  VALUE.  */; 

POINTER  2 : = POINTER  1 
/*  LEFT:  LEVEL  2; 

RIGHT:  NEXT  ALSO  LEVEL  2,  AFTER  ADJUST- 
MENT TO  LEFT  SIDE  LEVEL  1,  I.  E.  THE  VALUE 
(HERE  A),  INDICATED  BY  THE  POINTER  1 WILL 
BE  ASSIGNED  TO  POINTER  2,  AFTER  WHICH 
BOTH  ADDRESS -VARIABLES  INDICATE  A.*/; 

POINTER  1 : = 3.9 

/♦  LEFT:  LEVEL  2; 

RIGHT:  LEVEL  0; 

FALSE,  BECAUSE  BOTH  SIDES  ARE  NOT  AUTO- 
MATICALLY ADJUSTABLE.*/; 

VALUE  POINTER  1 : ^ 3.9 

/*  LEFT:  LEVEL  1 BECAUSE  OF  THE  OPERATOR 

VALUE  APPLICABLE  TO  THE  ADDRESS -VARIA- 
BLE; RIGHT  : LEVEL  0; 

EFFECT:  AS  FOR  A :=  3.9,  BECAUSE  POINTER  1 
INDICATES  A.  */; 

Also  see  example  under  2.2.3. 

Further  details  regarding  the  handling  of  ADDRESS 
variables  are  not,  as  yet,  finalized. 


2.2.2.  Compound  Types 
2. 2. 2.1.  Arrays 

Arrays  consist  of  elements  of  the  same  type.  This  type 
can  be  a basic  type  with  the  exception  of  SEMA  and 
FILE,  or  a structure. 

An  example  of  a declaration  for  a two-dimensional  array 
with  elements  of  the  type  REAL  and  with  the  identifier 
MATRIX  is  as  follows: 

(5:100,1:7)  REAL  (10)  MATRIX 

When  transposing  arrays  to  storage,  the  last  subscript, 
i.  e.  the  subscript  at  the  extreme  right-hand  location, 
will  be  transposed  one  at  a time  ( Tine"  transposition). 

An  element  in  an  array  will  be  addressed  by  an  array 
identifier  and  a subscript  list. 

Example:  MATRIX (7 «.T, 3)  /*  E.  G.  J = 4 */ 

Furthermore,  sections  of  an  array  can  be  addressed, 
which  consist  of  more  than  one  element. 


MATRIX  (,  2)  or  MATRIX  (• , 2) 

2)  Call  of  a section  of  the  second  column  of 
the  matrix  declared  above: 

MATRIX  (8  :N,  2)  /*  E.  G.  N - 55  */ 

According  to  this,  the  whole  matrix  could  be  addressed  by 
MATRIX  (,)  or  MATRIX  (*,*) 

the  array  identifier  alone  is,  however,  sufficient  for  this 
purpose. 

Examples  of  array  constants: 

1)  Constant  vector  with  three  components: 

(6,  7,  9) 

2)  A matrix 
(3  -5 

\ 7 9 ' 

will  be  written  as  : 

((3,-5),  (7,  9)) 

2. 2. 2. 2.  Structures 

Structures  will  be  formed  from  elements  of  (not  necessa- 
rily) different  types.  The  type  of  a particular  element 
can  be  a basic  type  with  the  exception  of  SEMA  and  FILE 
or  a structure  or  an  array. 

Structure  identifiers  will  be  declared  similarly  to  those 
in  ALGOL  68,  whereby  the  structure  type  is  used  either 
directly  as  the  declaration  symbol,  or  by  using  a decla- 
ration symbol  which  has  been  explicitely  declared  in  a 
type  declaration. 

Example:  Declaration  of  an  identifier  (e.  g.  C)  for  com- 
plex values : 

1st  possibility:  STRUCTURE  (REAL  RE,  REAL 
IM)  C ; or  shorter ; 

STRUCTURE  (REAL  RE,  IM) 

C; 

2nd  possibility  : TYPE  COMPLEX  = STRUC- 
TURE (REAL  RE,  IM) 

/*  PURE  TYPE  DECLARA- 
TION */; 

COMPLEX  C 
/*  (NOT  NECESSARILY 
DIRECTLY)  FOLLOWING 
IDENTIFIER  DECLARATION*/; 

The  declaration  of  a structure  type  therefore  contains 
a list  of  the  elements  of  the  structure.  The  list  elements 
each  contain  a declaration  syn  ool  (e.  g.  REAL,  INTEGER 
etc.)  and  an  identifier  which  is  u„ed  to  address  the  struc- 
ture element  so  designated  (see  lielow).  If  the  same  de- 
claration symbol  applies  to  a consecutive  sequence  of 
list  elements,  it  only  has  to  be  located  with  the  first  list 
element  (seelst  possibility  in  example  above). 

A structure  element  is  addressed  by  an  element  identi- 
fier and  a structure  identifier. 

Example : RE  OF  C resp.  IM  OF  C 
or  shorter  : 

RE.C  resp.  IM.C 

An  element  of  a structure,  which  is  itself  an  element  of 
an  array,  will  be  addressed  by,  e.  g. 
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ELEMENT 3 . ARRAY (I) 


2.3.  Operators 
2.3.1.  Classification 


An  element  of  an  array,  which  is  itself  an  element  of  a 
structure,  will  be  addressed  by,  e.  g. 

ELEMENT  2 (I)  . STRUCTURE 

Examples  of  structure  constants: 

1)  (5.7,  '1  Ol'D,  II 5, 'ABC') 

2)  Two  element  structure  constant,  whose  first  element 
is  also  a structure  : 

((5.7, 'ABC'),  97) 

3)  Structure  constant,  whose  second  element  is  an 
ADDRESS  constant: 

(5.7,  ANTON) 

4)  Structure  constant,  whose  second  element  is  a one- 
dimensional  three  element  array  constant: 

(5.7, (1,2,1)) 

2.2.3.  Example  of  a circular  concatenated  list 

(1  : 100)  STRUCTURE  (REAL  CONTENTS,  ADDRESS 
REFERENCE)  LIST 

/*  DECLARATION  OF  THE  IDENTIFIER  LIST  WHICH 
INDICATES  AN  ARRAY  OF  STRUCTURE 
ELEMENTS.  ♦/} 

FOR  I TO  99  DO  REFERENCE  . LIST  (I)  : - LIST  (I + 1); 
REFERENCE.  LIST  (100)  :=  LIST(l) 

* OCCUPANCY  OF  THE  STRUCTURE  ELEMENT 
REFERENCE  IN  ALL  LIST  ELEMENTS  WITH  THE 
SUBSCRIPTED  IDENTIFIER  OF  EACH  OF  THE 
NEXT  LIST  ELEMENTS.*/: 

ADDRESS  POINTER  : = LIST  (100) 

* DECLARATION  OF  THE  ADDRESS-VARIABLE 
POINTER  WITH  INITIALIZATION.  */; 

The  result  is  illustrated  by  figure  1. 

An  entry  into  the  list,  thus  prepared,  will  be  effected  by 
the  following  two  statements : 

POINTER  : = REFERENCE. VALUE  POINTER 

* SET  POINTER  TO  NEXT  LIST  ELEMENT.*/: 

CONTENTS  . VALUE  POINTER  : = /*  CONTENTS  TO  BE 
ENTERED  */; 

2.2.4.  Conversions  between  data  of  different  types 

Type  conversions  which  are  required  frequently  in  ex- 
pressions, are  done  automatically.  Standard  functions 
are  provided  for  further  conversions.  When  the  compiler 
recognizes  that  a type  conversion  is  to  be  made  in  an 
< -t  ion  a warning  message  may  be  output. 


Provision  has  been  made  for  the  monadic  operators  + 
and  - for  arithmetic  operands,  NOT  for  BINAL  operands 
as  well  as  VALUE  for  ADDRESS  variables  and  the  follo- 
wing dyadic  operators : 

1)  for  arithmetic  operands: 

exponentiation 
integer  division, 

remainder  of  integer  division  (modulo), 

normal  division, 

multiplication, 

addition, 

subtraction 

and  the  conventional  six  comparisons 

( ' > & i - i * ) 

2)  for  BINAL  operands: 

conjunction, 

disjunction, 

equivalence, 

antivalence, 

shift  (direction  indicated  by  the  sign  of  the  number  of 
shift-steps),  selection  of  an  individual  bit  and  conca- 
tenation. 

3)  for  STRING  operands: 

concatenation 
and  comparisons; 

4)  for  ADDRESS  operands: 
comparisons. 

2.3.2.  Operator  Declarations 

Operator  declarations  are  provided  with  the  restriction 
that  only  operator  symbols  which  already  exist  can  be 
extended  to  newly  declared  types  by  using  such  a decla- 
ration; the  existing  operator  priorities  must  not  be 
altered. 

2.4.  Executable  Statements 
The  following  are  provided : 

- assignments, 

- go  to  statement, 

- repetitive  statement  similar  to  ALGOL  68, 

- switch  statement  similar  to  CASE  clause  in  ALGOL  68, 

- compound  statement, 

- conditional  statement  (IF  statement  in  ALGOL  60), 

- interrupt  response  (ON  statement,  see  4.3.1.), 

- task  statements  (see  4.2.) 

- procedure  statement  (see  2.1.4.), 

- statements  for  SEMA  variables  (see  4.4.3.). 
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2.5.  Standard  Functions  and  Standard  Procedures 

Besides  ihe  usual  mathematical  standard  functions, 
standard  functions  and  standard  procedures  for  bit  hand!  ing 
are  also  provided  (selection  of  bit  sequences  from  BINAL 
-5ata);  string  handling  (selection  of  characters  and  cha- 
racter sequences  from  STRING  data),  type  conversions, 
input  output  (see  5.)  and  special  functions  are  likewise 
provided  for. 


3.  The  System  Division 

3.1.  Purpose 

The  system  division  connects  the  actual  process- 
program  with  the  environment.  It  is  used  to  describe  the 
machine  configuration  on  the  language  level. 


3.3.  Computer  Description 

The  begin  of  this  part  is  identified  by  the  keyword 
MACHINE,  it  contains  information  about: 

a)  type  (keyword:  MODEL) 

b)  features  of  the  processing  unit 

c)  si/e  of  working  storage  (keyword:  SIZE) 

d)  chancels  (keyword:  CHANNEL) 

The  information  to  be  supplied  in  a special  case  will 
have  to  be  provided  in  the  corresponding  manual. 

As  one  "PEARL'*  compiler  will  be  written  for  a whole 
computer  family,  it  must  be  informed  about  file  actual 
level  and  the  features  of  the  implementation,  to  be  able 
to  guarantee  an  optimal  use  of  the  computer  by  means 
of  a specially  optimized  object  program. 


It  contains  parts  of  a "job  control  language",  it  supplies 
information  for  the  generation  of  that  part  of  the  opera- 
ting system  that  is  necessary  for  the  special  program 
and  it  allows  an  optimization  of  resource  allocation.  II 
further  connects  external  devices  ,uid  process  interface 
hardware  with  symbolic  names,  that  are  to  be  used  in 
the  problem  part. 


3.4.  Configuration  Description 

3.4.1.  Purpose 

a)  The  operating  system  is  informed  about  the  peripheral 
devices  to  be  used  by  the  program.  For  the  specified 
environment  an  optimal  version  of  the  operating  sy- 
stem may  be  generated. 


An  extensive  use  of  symbolic  names  in  the  problem 
division  makes  programming  easier  and  improves  the 
readability  of  the  computer  program. 

By  th<  computer  description  the  compiler  is  in- 
formed about  e.g.  the  type,  model  and  memory  size  of 
the  machine  used. 

The  confi  ••  at  i on  description  specifies  the 
extend  and  tin-  structure  of  the  used  peripherals.  Each 
external  device  and  process-interface  is  connected  with 
an  identifier.  In  the  same  instiuice  the  datapath  from  the 
, -ntr.il  unit  to  the  terminal  device  is  described.  By  na- 
min' only  those  peripherals  that  are  used  by  the  pro- 
gram.  t m;  be  possible  to  minimize  the  I/O-package 
linked  to  the  program. 

In  t De  interrupt  description  the  interrupts  gene- 
rated by  the  system  are  matched  with  identifiers,  that 
can  be  referred  to  in  the  problem  division.  Here 
also  a certain  optimisation  of  the  interrupt  decoding 
routines  may  lie  performed. 

In  the  flag  description  status  information  of  the 
hardv  ire  is  depicted  onto  BINAL  strings,  and  can  so  be 
tested  in  the  problem  part. 

3.2.  Syntax  of  the  System  Division 

SYSTEM  , 

MACHINE; 

/*  COMPUTER  DESCRIPTION  */ 

EQUIPMENT; 

/•  CON  FIGURATION  DESCRIPTION  V 

INTERRUPT;  Co, 

'•  INTERRUPT  DESCRIPTION*/ 

FLAG; 

/*  FLAG  DESCRIPTION  */  , 


b)  As  the  actual  equipment  with  peripheral  devices  is 
not  specific  to  the  computer  but  to  the  whole  installa- 
tion, and  can  be  changed  from  time  to  time,  the  whole 
datapath  from  the  central  unit  to  the  terminal  device 
must  be  described  definitely.  This  can  generally  be 
done  by  means  of  an  "address  tree",  the  nodes  of 
which  are  represented  each  by  a control  unit  with 
special  attributes  and  interface  specifications.  (Fig.  2) 

c)  Identifiers  are  adjoined  to  the  special  datapaths, 
which  are  used  in  the  problem  division. 

3.4.2.  Syntax 

EQUIPMENT; 

[STANDARD  ( ; TOTAL] 

[ ; identification]  . . . ; ] 

[SPECIAL  f ; identification]  . . . ; ] 

The  metavariable  identification  is  expanded  as  follows : 

identification  : : - identifier  [ (index-list)  ] - 

[computer-link]  ]*  ' * ] [channel-type 
( , attribute]  . . . f (index-list)  ] ] 

] * | * } ...  [terminal-type  | ; 

Index-list  is  a list  containing  positive  integers,  similar 
to  that  in  a loop-specification;  an  item  of  the  list  can 
be  a single  number  (e.  g.  2,  7, 11),  a range  of  numbers 
(e  g.  3:10,  17:  21 ),  or  a range  of  numbers  with  an  incre- 
ment (e.  g.  4 (3)  16  means  the  series  4,  7, 10, 13, 16)  .*  or  -- 
represent  a node  in  the  address  tree. 
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has  an  additional  function:  for  two  consecuttve  sym- 
bols x that  part  of  the  previous  datapath  description  that 
• s enclosed  in  two  symbols  * is  substituted. 

Examples : 

1.  DISK  1*KW,  2*ZWW,  FLOAT*ST05A  ; 

The  disk  of  type  ST05A  shall  be  connected  via  the 
floating  data-channel  ZWW  and  the  2nd  exit  of  the 
t 0-processor  KW  to  exit  1 of  the  computer. 

T The  system  of  fig.  2 could  be  described  as  follows : 

TERMINAL.  (1  :4)=XKYZ,  1*MPX1  (1, 2, 4,  5)*CIRCLE  ; 
TERMINAL  (5  : 8)  XKYZ,  2*MPX2  (3  : 6)*SQUARE  ; 

3.)  Sui'stitution  of  parts  of  the  datapath  description 
shows : 

FIRST  10PROCA  --  CHAN  1 ’CONTROL  2 * DEVICE  1; 
SECOND  10  PROCB  * * DEVICE  2 

MEANS:  SECOND  = 10 PROCB* CHAN  1* 

CONTROL  2 = DEVICE  1 */ ; 

i. 4. 3.  Semantic  of  the  Configuration  Description 

EQUIPMENT  introduces  the  configuration  description, 
STANDARD  that  of  the  standard  peripherals,  SPECIAL 
that  ot  process  oriented  peripherals.  TOTAL  means:  all 
at  the  standard  peripherals  connected  to  the  system  shall 
be  used. 

Standard  peripherals  have  a fixed  datapath.  They  are 
identified  by  a name  that  is  defined  by  the  implementa- 
tion (this  "name"  may  also  be  an  integer);  it  may  be 
hanged  in  the  system  division.  Both  identifiers 
may  be  used  in  the  problem  division.  This  is  use  - 
ful,  if  a program  is  composed  of  parts  of  different 
origin,  or  if  peripherals  are  replaced  by  devices  of 
another  type  (but  with  the  same  function  with  respect  to 
the  program). 

identification  describes  the  datapath  by  a series  of  type 
and  address  items.  Details  (the  keywords  and  the  local 
syntax  of  channel-types  and  attributes)  depend  on  the 
implementation  and  can  be  taken  from  the  manual  and 
the  hardware  plan  of  the  installation. 

The  identifier  defined  in  the  system  division  is  used  in 
the  problem  division  as  an  actual  parameter  of  I/O  and 
library  procedures  and  stands  for  the  device  address 
resp.  device  number.  Further  parameters  are  not  supp- 
lied by  the  system  division. 

it  a one  dimensional  array  of  identifiers  is  adjoined  to 
a set  of  identical  process  terminals,  this  is  described 
ny  index-list. 


[STANDARD] ; TOTAL]  f ; interrupt-identifier]  . . . ; j 
[SPECIAL]  ; TOTAL]  [ ; interrupt  identifier]  . . . ;] 

The  metavariable  interrupt-identifier  is  expanded  as 
follows : 

[identifier  =]  . . . implementation  dependent  dest  riptor  ; 

3.5.3.  Semantics 

The  interrupts  listed  in  the  interrupt  description 
can  be  addressed  with  the  corresponding  symbolic  names 
in  the  problem  division.  The  interrupts  not  mentio- 
ned in  the  system  division  are  disarmed,  disabled 
or  handled  by  dummy  routines.  The  priorities  of  the 
interrupts  and  the  handling  routines  are  prescribed  by 
the  order  of  the  interrupt  list,  if  this  is  allowed  by  the 
system. 

Interrupts  of  type  STANDARD  have  predefined  names.  It 
is  desirable,  that  interrupts  of  the  same  origin  should 
have  identical  names.  The  " PEARL"  - committee  will 
issue  proposals  for  that. 

Interrupts  of  type  SPECIAL  are  handled  over  from  the 
operating  system  to  the  user  program;  they  are  specific 
for  the  particular  process. 

Double  definitions  are  possible. 

Example:  HEATALARM  = PRESSUREALARM  = 37; 

In  many  cases  the  system  supplies  further  information 
during  an  interrupt.  It  can  be  accessed  by  the  standard 
procedure  STATUS  (interrupt-identifier). 

3.6.  Flag-Description 

3.6.1.  Flags  are  status  messages  of  the  peripherals  or 
of  the  computer,  that  do  not  cause  an  interrupt.  The  ope- 
rating system  is  informed,  which  of  them  will  be  used. 

3.6.2.  Syntax 
FLAG];  TOTAL]  ; 

[flag-identifier  =]  . . . operating  system  defined  name  of 
the  flag; 

3.6.3.  Semantics 

flag- identifiers  are  used  like  BINAL  strings  in  the  pro- 
blem division,  e.  g.  in  conditional  statements.  Further 
information  may  be  accessed  v a a standard  procedure 
STATUS  (flag-identifier)  in  this  case,  too. 


Example : 

APCfl  : 1 2)  CCTR*3*(1, 3,5:7,  12  : 18)*5»KAD  5; 

Also  arrays  of  names  may  be  redefined: 

HEAT  (1:50)  TEMP  (20:  69); 

3.5.  Interrupt  description 
3.5.1.  Purpose 

The  operating  system  is  informed  about  the  interrupts 
o be  used.  These  are  "logical  interrupts",  which  not 
necessarily  have  their  origin  in  the  hardware  and  may 
include  additional  information  about  the  status  change 
•using  the  interruption.  It  shall  be  possible  to  generate 
>r  simulate  an  interrupt  by  the  program  (see  4.3.2.). 


4.  TASK-M  an  age  m e n t 
4.1.  Problem 

Contrary  to  a sequentially  evented  program  for  ofl-line 
calculation  of  results  from  a set  of  data,  loaded  once 
only,  wnere  the  chronological  order  ot  operations  is 
necessarily  obtained  from  the  program  and  the  data 
programs  for  on-line  control  and  evaluation  of  ri.P- 
from  industrial  processes  and  experiments  have  an 
entirely  different  structure:  They  consist  of  manv  short 
sections  which  are,  individually  speaking,  sequentially 
executed,  but  which  .ire,  regarding  the  entire  process, 
executed  quasi  parallel.  They  are  also  interrupted  iiv 
time  internals  in  nich  the  computer  d- •«•>*  not  have  to 
compute  for  the  process 
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This  structure  is  inevitable,  because 
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(a)  the  computer  must  be  able  to  react  quickly  in  re- 
sponse to  the  many  external  demands  which  occur 
statistically  in  time, 

(b)  the  urgency  of  the  reactions  is  differentiated  so  that 
every  reaction  can  be  interrupted,  replaced  and 
continued  later  in  favour  of  another  reaction. 

The  task-management  has  to  enable  this  quasi-parallel 
execution  and  to  control  its  timing. 

4.2.  The  "Task" 

4.2.1.  Definition 

A user -program  is  executed  in  sections  which  are  called 
"tasks".  The  base  of  such  a task  is  a statement,  or  a se- 
quence of  statements  combined  to  form  a block.  Jumps 
out  of  this  block  are  not  permitted. 

The  dynamic  execution  of  this  sequence  ol  statements, 
under  control  of  the  operating  system  defines  a task.  A 
task  can  demand,  from  the  operating  system,  the  execu- 
tion of  additional  self-contained  sequences  of  statements, 
whereby  new  tasks  ("subtasks")  will  be  generated. 

This  generating  process  may  be  performed  in  several 
stages.  Tasks  are  simultaneously  executed,  as  far  as  the 
devices  (computer  and  peripheral  units)  permit. 

4.2.2.  Priorities 

If  several  tasks  simultaneously  demand  the  use  of  the 
same  device  or  unit,  the  operating  system  will  decide, 
according  to  their  priority,  to  which  of  the  competing 
tasks  the  unit  will  be  allocated.  The  user  assigns  the 
priorities  to  the  tasks.  When  not  all  of  the  devices  re- 
quired by  a task  are  allocated  to  it,  then  the  task  is 
placed  in  the  "waiting  state".  The  priority  of  a task  is 
a natural  number.  The  lower  the  number,  the  higher  tire 
priority.  The  operating  system  selects  the  task  which 
will  be  executed  first,  if  two  or  more  have  the  same 
priority. 

4.2  3.  Task-Generation 

A task  is  generated  by  the  statement 

ACTIVATE  task-name  [ WITH  PRIORITY  priority- 
number  j : statement ; 

where  taks-nnme  is  the  identifier  which  addresses  the 
task,  priority-number  the  priority  of  the  task  and  state- 
ment the  code  to  be  activated. 

If  WITH  PRIORITY  priority-number  is  missing,  the  new 
task  is  assigned  the  priority  of  the  generating  task; 
task-name  must  be  declared  as  TASK. 

Activation  of  a task  means  to  connect  the  task  name  with 
the  code,  to  set  the  priority  and  to  notify  the  operating 
system  of  the  code  to  be  executed.  Tasks  having  the 
same  name  must  not  be  activated  at  the  same  time. 


4.2.4.  Task  Operations 

Other  operations  which  have  an  effect  on  a task  are : 

a)  TERMINATE  task-name; 

b)  DELAY  task-name; 

c)  CONTINUE  task-name  [WITH  PRIORITY  priority- 

number  I ; 


TERMINATE  ends  a task  and  all  its  activated  sub-tasks 
(non-interruptible  operations  which  have  already  been 
started  will  be  finished  first). 

DELAY  transfers  a task  into  the  waiting  state  (but  not 
its  subtasks). 

CONTINUE  cancels  this  waiting  state  (i.  e.  re-activates 
t he  task). 

Furthermore, 

CONTINUE  task-name  WITH  PRIORITY  priority-number; 

is  used  to  change  the  priority  of  the  addressed  task. 

If  the  addressed  task  does  not  exist,  i.  e.  either  it  has  not 
been  activated,  or  it  is  already  terminated,  then  the  task 
operations  will  lie  interpreted  as  dummy  operations. 

In  addition  to  this  there  is  another  standard  function 

PRIORITY  (task-name). 

which  supplies  the  priority  of  the  task  task-name, 
as  a result,  if  the  task  exists;  otherwise  the  result  will 
bn  a negative  number. 

4.2.5.  Time  Control  of  Tasks 

In  all  task  operations  the  time  of  their  execution  may  be 
specified  as  follows: 

TAT  time  1 j [EVERY  time-interval  [UNTIL  time  2]] 
task-operation ; 

This  type  of  statement  results  in  the  execution  ot  the 
specified  task-operation  in  intervals  of  time-interval 
iroin  time  1 to  tinie2.  If  AT  time  1 is  left  out,  task-ope- 
ration will  be  executed  for  the  first  time  when  this 
statement  is  executed.  If  EVERY  time-interval  UNTIL 
time 2 is  left  out,  then  a "once  only"  execution  of  task- 
operation  follows.  In  the  case  that  UNTIL  time  2 behind 
EVERY  time-interval  is  missing,  then  task-operation 
will  be  repeated,  providing  that  the  task  still  exist  ' 
which  contains  the  pertinent  statement. 

Further  activations  of  a task,  caused  by  a statement 
which  lias  already  been  executed,  such  as  EVERY  tirne- 
interval  ACTIVATE  task-name;  can,  nevertheless,  be 
hindered  by  using  another  task  operation 

PREVENT  task-name; 

PREVENT  is  ineffective  if  no  further  activations  are 
queued  for  the  addressed  task. 

4.2.6.  Task  End 
A task  ceases 

a)  when  the  task  and  all  its  subtasks  have  executed 
their  last  statement 

b)  if  it  is  ended  by  TERMINATE. 

If  the  end  of  a block  is  reached,  during  execution  of  a 
task,  the  execution  will  be  continued  only  after  all  acti- 
vated sub‘asks  in  the  block  are  finished. 

4.3.  Alarms 

4. Reaction  io  Alarms 

Reactions  to  alarms  are  specified  by  the  statement 
ON  alarm  : statement; 

where  alarm  is  the  identifier  of  a logical  interrupt  and 
statement  is  the  code  to  be  executed  in  response  to  the 
inter' upt;  statement  will  always  be  executed  with  the 
highast  priority.  ’rhis  execution  is  non-interruptible. 
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4.3.2.  Signal 

A logical  interrupt  interrupt  can  be  generated  or  simu- 
lated in  the  user  program  (e.  g.  for  test  runs)  by  the 
statement : 

SIGNAL  interrupt; 

4.3.3.  Disconnection 

If  several  ON  statements  refer  to  the  same  interrupt, 
then  the  last  one  to  be  executed  in  the  block  is  valid. 

When  exiting  a block,  the  last  valid  ON  statement  in  the 
next  outer  block  is  effective.  If  it  should  occur  that  in 
none  of  the  outer  blocks  an  ON  statement  is  executed, 
then  there  is  no  further  response  to  this  interrupt. 

An  interrupt,  at  a distance  as  far  as  possible  from  the 
central  unit  permitted  by  the  implementation  concerned, 
can  be  switched  off  by  using 

DISABLE  alarm ; 

The  interrupt  can  be  switched  on  again  by 
ENABLE  alarm : 

4.4.  Semaphore 

4.4.1.  Problem 

Since  the  timing  sequence  of  operations  in  two  tasks 
running  parallel  with  each  other  cannot,  in  many  cases, 
be  completely  arbitrary,  means  must  be  provided 
whereby  the  desired  sequence  of  such  operations  can 
be  attained.  For  instance  — before  the  output  of  an  array 
by  a task,  this  array  has  to  be  filled  in  by  another  task. 

If  this  sequence  is  accidentally  reversed  then  the  results 
are  senseless.  For  the  synchronization  of  tasks  running 
parallel  with  each  other,  semaphore  variables  and  non- 
interruptible  semaphore  operations  which  have  an  effect 
on  the  semaphore  variables  are  used. 

4.4.2.  Features  of  the  Semaphore  Variables 

Semaphore  variables  are  initialized  at  the  same  time  as 
their  declarations.  Further  access  to  a semaphore  variable 
is  only  possible  via  a semaphore  operation. 

4.4.3.  Operations 

Semaphore  operations  are  non-interruptible.  The  follo- 
wing operations  are  available: 

REQUEST  sema 
RELEASE  sema 

The  operation  REQUEST  decrements  the  value  of  the 
semaphore  variable  sema  by  one,  providing  that  the 
result  is  not  negative.  If  the  result  were  negative,  the 
task  which  is  trying  to  decrement  the  semaphore  va- 
riable will  be  placed  into  the  waiting  state  until  the 
semaphore  variable  can  be  decremented  to  a non-nega- 
tive result. 

RELEASE  increments  the  value  of  the  semaphore  varia- 
ble sema  by  one  and  starts  the  tasks,  in  order  of  priority, 
which  had  previously  been  stopped  by  R EQUEST  operations. 

Ttn  operators  RELEASE  and  REQUEST  may  operate  on 
lists  of  semaphore  variables.  Consequently, 

REQUEST  sema  f,  sema)...  : 

checks  whether  all  semaphore  variables  in  the  list  can 
lie  decremented  to  a non-negative  value.  If  this  is  im- 
possible, then  none  will  be  drecremented  and  the  opera- 
tion will  be  stopped  until  the  possibility  arises. 
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4.5.  Working  Storage  Allocation 

4.5.1.  Principle 

The  entire  code  of  a PEARL -program  will,  in  many 
cases  be  located  in  backing  storage  and  not  in  working 
storage.  Consequently  the  code  needed  for  a task  has 
to  be  loaded,  by  the  operating  system,  from  the  backing 
storage  to  the  working  storage.  The  operating  system 
determines  from  the  activation  statement  for  this  task, 
that  additional  code  is  required  as  well  as  the  identifi- 
cation of  this  code.  The  activation  statement  must  be 
executed  early  enough  so  that  the  loading  procedure  is 
finished  in  time.  Untimely  execution  of  the  task  can  lie 
prevented  by  using  SEMA  variables. 

4.5.2.  Code  of  a Task 

The  code  required  for  a task  consists  of  all  instructions 
which  may  be  performed  and  all  data  which  will  be  for- 
mally used  therein.  In  particular,  all  procedures  which 
will  be  called  in  the  task  (possibly  via  several  stages) 
belong  to  the  code.  The  requirements  of  a sub-task,  e.  g. 
its  instruction  sequence,  do  not  form  part  of  the  code  of 
the  task  activating  it. 

As  in  RTL  [4],  procedures  and  data  will  not  be  loaded 
together  with  the  block  containing  their  declaration,  but 
together  with  the  instruction  sequences  in  which  they 
will  be  (formally)  called  or  used. 

4.5.3.  Block  Residence 

It  is  possible  for  the  PEARL-programmer  to  load  pro- 
cedures, i.  e.  their  instructions  and  data,  together  with 
the  code  of  a task  not  containing  a call  fur  them.  This 
is  atlained  by  the  statement 

RESIDENT  procedure-call  [,  procedure-call)  . : 

The  effect  as  regards  loading  is  the  same  as  that  of 
calls  located  in  the  same  position.  Hence  RESIDENT 
applies  only  the  block  in  question. 

4.5.4.  Displacement 

For  loading,  the  section  of  working  storage  which  is  not 
occupied  with  instructions  or  data  of  an  existing  task 
will  be  used  first  of  all.  If  this  space  is  no  longer  avai- 
lable, then  the  code  of  a sufficient  number  of  tasks  which 
are  either  in  the  waiting  state  or  have  a lower  priority 
than  the  task  to  be  newly  activated,  will  have  to  be  dis- 
placed from  the  working  storage.  The  data  to  be  displa- 
ced must  not  be  overwritten  and  must,  therefore,  be 
previously  transferred  into  the  backing  storage.  If  there 
are  no  tasks  with  lower  priority  than  the  one  be  newly 
activated,  then  it  will  be  placed  in  the  waiting  state. 

4.5.5.  Reload 

Generally  speaking,  tasks  to  be  newly  activated  often 
require  data  and  procedures  which  have  already  been 
called  or  used  by  tasks  which  chronologically  precede 
them,  and  which  are  consequently  still  located  in  wor- 
king storage.  This  raises  the  problem  for  the  operating 
system  of  not  only  determining  the  additional  code  re- 
quired, but  also  of  linking  this  code  to  sections  which 
are  already  in  the  working  storage. 

Whether  this  is  possible,  and  how  to  achieve  it.  depends 
largely  on  the  computer  system  in  use  and  its  operating 
system.  Since  working  storage  allocation  is  controlled 
by  priorities,  it  may  be  necessary  to  restrict  the  prio- 
rities of  sub-tasks  in  order  to  obtain  effective  imple- 
mentation. 
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identifiers,  option  describes  control  information  which 
is  probably  necessary  for  special  modes. 
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5.  Input /Output 
5.1.  Basic  Principles 


If  one  attempts  to  handle  all  known  I/O-facilities  from  a 
uniform  point  of  view,  even  in  commercial  or  scientific 
data-processing-applications  difficulties  arise ; e.  g. 
external  storage  devices  with  either  random  or  sequen- 
tial access  should  be  addressed  in  the  same  manner. 
Apart  from  that  there  are  functionally  very  different 
I/O-devices  (compare  a teletypewriter  with  a CRT)  that 
shall  be  handled  with  procedures  that  are  as  similar  to 
each  other  as  possible. 

The  additional  peripheral  devices  of  a computer  that  is 
used  for  data  acquisition  and  control  of  industrial  pro- 
cesses and  scientific  experiments  enlarge  the  difficul- 
ties of  a standardized  I/O-description.  In  this  section  it 
is  tried  to  develop  a syntactically  uniform  description 
of  all  I/O-facilities. 

Primarily  the  uniformity  of  the  description  is  achieved 
by  the  formulation  of  procedures  for  all  I/O-functions. 

In  the  forma!  handling  this  corresponds  to  the  possibi- 
lities that  are  provided  in  ALGOL  60  and  68. 

In  FORTRAN  and  PL/1  1/0-transfers  are  formulated  as 
special  statements,  but  also  in  these  languages  they  are 
implemented  as  subroutines. 

In  PEARL  this  procedure  concept  yields  another  advan- 
tage : we  have  the  possibility  to  easily  activate  I/0-ope- 
rations  in  a sequential  and  in  a parallel  manner: 

ACTIVATE:  OUTPUT  1 (CA,  RAM,  BA);  describes  output 
done  in  parallel  with  the  execution  of  the  following  state- 
ments. 

The  procedure  call  "OUTPUT  2 (TOM,  DOOLEY);" 
without  the  prefixed  ACTIVATE  starts  the  1/0-procedure 


Six  mode-descriptors  seem  to  be  sufficient: 

PRIMITIVE 

BINARY 

CHARACTER 

GRAPHIC 

CALIBRATED 

CONTROL 

Suitable  abbreviations  of  these  keywords  will  be  defined 
later  by  the  PEARL-committee. 

5.2.  Syntax,  Semantics  and  Function  of  the 
1/0-Procedures 

5.2.1.  PRIMITIVE  Input/Output 

Syntax : 

INPRIMITIVE  | , , . . . . . 

IOUTPRIMITIVE  ((external-termlJla1'  internal-terminal 
f,  control-information]); 

control-information  is  a list  of  variable  identifiers 
and/or  constants  containing  control  information  for  the 
data  transfer. 

Semantics : 

The  procedures  INPRIMITIVE  and  OUTPRIMITIVE  are 
used  to  transfer  data  from  a terminal  device  to  working 
storage  and  vice  versa;  information  for  datapath-  and 
device-control  must  be  provided  explicitly  by  the  pro- 
grammer. This  can  be  done  by  the  control-information 
included  in  the  same  procedure  call  or  by  a previous 
output  of  control  information  only. 


Examples : 

1)  INPRIMITIVE  (DEVICE  1,  DATA,  '101101101  111'  B) 

/♦TRANSFER  FROM  DEVICE  1 TO  THE  VARIABLE 'DATA' IS 
CONTROLLED  BY  THE  BINAL  STRING  OF  PARAMETER  3*/; 

2)  X : = '00000100'  B; 

AB  :=  '0110' B; 

OUTPRIMITIVE  (PROCON3,  X,  AB) 

/♦THE  FOLLOWING  INFORMATION  IS  TRANSFERRED  TO 
PROCESSCONTROLUNIT  3 : 

AB  IS  INTERPRETED  IN  THAT  WAY  : 01  SELECT  THE  2ND  OF  4 STEP 

MOTORS, 

10  TURN  CLOCKWISE, 

AND  X : TRANSFER  THE  VALUE  4 TO  THE  MOTOR’S  STEP  COUNTER  */; 


as  a s broutine.  This  means:  the  running  task  executes 
the  succeoding-siatement  after  the  termination  of  the 
1/0-operation. 

The  description  of  1/0  procedures  in  PEARL  is  charac- 
terized by  5 descriptors: 

direction,  mode,  external-terminal,  internal-terminal, 
option.  Direction  (IN  or  OUT  only)  and  mode  are  combined 
to  one  word  (the  name  of  the  procedure).  The  following 
three  descriptors  are  parameters  of  this  procedure. 

external-terminal  is  an  identifier  for  a device  or  a file, 
internal-terminal  defines  the  area  in  working  storage 
where  data  is  to  be  in-  or  outputted.  Syntactically  i*  is 
represented  by  a (if  necessary  parenthesized)  list  of 


Range  of  application : 

PRIMITIVE  Input/Output  permits  the  possibility  to  handle 
machine  code  on  language  level.  Primarily  it  is  necessary 
if  none  or  only  rudimentary  routines  for  handling  an 
addressed  peripheral  and  its  datapaths  exists  (e.  g.  new 
built  or  modified  hardware).  All  other  1/0-functions  can 
be  expressed  by  suitable  combinations  of  PRIMITIVE  1/0. 

5.2.2.  BINARY  Input/Output 
Syntax: 

INBINARY  1,  . , . ...  . . . n 

OUTBINMtY • (external-terminal,  internal-terminal) ; 


Semantics : 

The  procedure  OUTBINARY  transfers  data  from  working 
storage  to  a terminal  device  while  control  of  datapath  and 
device  functions  is  entirely  performed  by  the  operating 
system.  The  transferred  information  is  not  changed,  in 
particular  it  is  not  translated  into  any  other  code. 

In  the  same  manner  the  procedure  INBINARY  has  as  its 
result  an  automatic  transfer  without  data  transforma- 
tion. 

Range  of  application: 

The  procedures  for  binary  I/O  can  e.  g.  be  used  for  inter- 
. iediate  storage  of  fata  on  magnetomotoric  storage  de- 
vices (similar  to  .he  use  of  unformatted  I/O"  in  FOR- 
TRAN). Readingfrom  and  writing  onto  process  peripherals 
is  also  done  with  these  procedures  when  there  is  a stan- 
dard mode  of  transfer  and  no  calibration  of  data  is  ne- 
cessary. 

Example : 


5. 2. 3.1.  The  PICTURE-procedure 

The  single  parameter  ol  PICTURE  is  represented  by  a 
character-string  that  depicts  the  layout  on  the  external 
medium  (e.  g.  page  of  a line  printer)  both  in  length  and 
structure.  String  constants  are  inserted  into  the  string 
as  they  shall  be  outputted,  fields  that  are  to  be  filled 
with  variables  are  reserved  by  space  imprinted  with  the 
wanted  layout  structure. 

Example : 

The  variables  I (integer,  value  23),  B (real  array  with 
two  elements,  values  17.1  and  3.1»1012)  and  TXT  (string, 
value  'PEARL')  shall  appear  on  an  external  device  like 
teletype -writer  or  CRT,  connected  to  "RESULT -LIST  ", 
showing  this  layout : 

RESULT 

TEST  23  B1  = 17.1  B2  = 3.1E12 

THIS  WAS  A PEARL-PROGRAM 


INBINARY  (TEMP  (1:4),  KELVIN  (5:  8)) 

/*  INPUT  FROM  THE  FOUR  THERMOCOUPLES  'TEMP  (1)'  TO  'TEMP  (4)' 
IS  TRANSFERRED  UNCHANGED  FROM  THE  ADC  TO  THE  ELEMENTS  5 
TO  8 OF  ARRAY  'KELVIN'  */; 


5.2.3.  Input  and  Output  of  Characters 
Syntax : 

INCHARACTER  | , , . . . . . . . . 

1 OUTCHARACTER  1 (externaUterminal>  mternal-ternnnal, 

( FORMAT  (string),  PICTURE  (string),  SPECIALLAYOUT  (...)]) ; 


The  third  parameter  of  the  CHARACTER -procedures  is 
a format-describing  procedure,  the  parameter  of  which 
is  a character  string. 

Semantics : 

Together  with  the  data  transfer  a translation  (code-trans- 
formation) is  performed  character  by  character  between 
the  internal  mach  ne  representation  of  the  data  (which  is 
defined  by  the  special  machine  and  by  the  data  type)  and 
the  external  representation  (defined  by  the  device,  and 
occasionally  by  the  programmer,  included  in  the  format 
description).  Moreover  the  layout  of  the  data  on  the  ex- 
ternal medium  is  described  by  the  FORMAT -(or  PIC- 
TURE-) procedure. 

It  shall  be  possible  to  specify  special  layout  procedures 
instead  of  the  standard  ones  (e.  g.  procedures  that  inclu- 
de interpretation  of  commands  entered  on  a manual  input 
device). 

The  external-terminal  is  regarded  as  a book  as  in 
ALGOL  68  [13]  ; (also  refer  to  the  file  description  in 
2. 2. 1.5.1.  It  is  suggested  that  the  parameter -string  of 
the  FORMAT-procedure  should  be  identical  or  very  si- 
milar to  that  of  PL/1  [8]  (Probably  including  a code- 
definition facility).  This  features  should  be  supplemen- 
ted by  a new-defined  PICTURE-procedure  which  corres- 
ponds to  a layout-description  which  is  very  simple  to 
use. 

Yet,  it  is  discussable  that,  instead  of  the  aforegoing 
points,  tin  complete  concept  of  any  other  programming 
language,  which  has  advanced  text  editing  features,  may 
be  utilized. 


The  output  procedure  is  called  in  this  way : 

OUTCHARACTER  (RESULTLIST,  (I,B,TXT),  PICTURE 
(’RESULT 

TEST  # # B1  =#■#■  B2  = # $ * $ * * 

THIS  WAS  A «.*.«  -PROGRAM-  - 

The  variables  I,  B,  and  TXT  are  inserted  into  the  fields 
structured  with  the  symbols  *■  , $ and  e . Their  special 
meaning  is  : 

* : replace  with  a number 

S : replace  with  a special  symbol  (also  E in  exponent 
notation) 

e : replace  with  an  alphanumerical  symbol 

If  a string-constant  contains  these  symbols,  they  must 
be  enclosed  in  double  quotes.  Perhaps  further  special 
characters  will  have  to  be  used  for  picture  specifica- 
tions (e.  g.  for  suppression  of  leading  zeroes). 

The  purpose  of  this  modification  of  conventional 
PICTURE-proeedures  is  to  enable  the  user  to  describe 
the  exact  layout  of  the  text  without  any  shifting  caused 
by  delimiters. 

5. 2. 3. 2.  Range  of  application 

CHARACTER  I/O  shall  be  used  everywhere  where  cha- 
racter strings  (text  or  numbers)  are  in-/outputted.  The 
I/O-devices  will  in  most  cases  be  dedicated  to  man- 
machine  communication.  This  method  may  also  be  used 
to  handle  process  I/O  if  the  peripherals  use  alphanume- 
ric coded  data  representation. 
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Example : 

INCHARACTER  (ADC1,  VAR,  PICTURE  ('##*#uu')) 

* TH1-:  FIRST  FOUR  OF  THE  SIX  DECIMAL  POSITIONS  OF  ADC  1 
SHALL  BE  DECODED  AND  STORED  INTO  VAR  */; 

CHARACTER  I/O  is  also  useful  for  tape-  and  disk-like 

devices  if  they  are  e.  g.  used  as  buffer  storage  for  slow  Fig.  3 

peripherals.  Example  of  a RANDOM 

pomt  display 


5.2.4.  Graphic  Input/Output 

By  means  of  this  procedure  all  I 0 related  to  graphs  and 
pictures  can  be  described.  It  handles  the  typical  graphic 
devices  like  plotters  or  CRT-displays,  but  also  the 
drawing"  of  a curve  by  means  of  a typewriter  with 
points  represented  by  some  letter  (e.  g.  V)  will  be  done 
using  the  GRAPHIC  mode. 


2)  SPECTR  : = (40.0,  35.0,  25.0,  15.0,  13.0,  17.5,  25.0, 

31.5,  37.0,  39.0,  40.0,  39.5,  37.5,  33.0, 

22.5,  10.0,  5.5,  3.0,  2.0); 

OUTGRAPHIC  (DISPLAY,  SPECTR,  INCREMENT  (2.5)) ; 
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5. 2. 4.1.  The  output  Procedure  OUTGRAPHIC 
Syntax : 

OUTGRAPHIC  (external-terminal,  internal-terminal, 
layout -procedure  (par, ...)); 

The  user  of  PEARL  will  be  supplied  with  a number  of 
standard  layout -procedures  for  graphic  editing.  He  may 
as  well  write  his  own  routines  for  that  purpose. 

Standard  layout -procedures : 


Fig.  4 

Example  of  an 
INCREMENTal  display 


no. ; 

internal  data : 

procedure 
name : 

parameters : 

graphic  picture 

1) 

x,  v [,  intens’.] 

RANDOM 

intensity, 

scale 

see  example  1) 

2) 

y f , intens.] 

INCREMENT 

intensity, 

y-scale, 

x-increment 

see  example  2) 

3) 

x,  y,  intens. 

LINE 

scale 

see  example  3) 

4) 

x,  y for  vj 

INTERPOL 

intensity 
scale,  mode 
of  interpolatn. 

see  figure  6 

5) 

x,  y,  r,  i? , , </5a 

CIRCLE 

scale,  inten- 
sity 

The  basic  method  of  graphic  layout  is  the  RANDOM  point 
plot  (1),  points  on  the  image  correspond  to  pairs  of 
values  (coordinates)  in  a data  array.  The  image  may  be 
modified  by  specification  of  scale  factors  and  of  the 
brightness  of  the  points  (if  possible).  With  INCREMENT 
point  plot  the  facility  of  many  graphic  devices  to  gene- 
rate y.-coordinates  automatically  (1,  2, . . . n)  is  described 
(2).  The  programmer  must  provide  the  y-data  only. 

With  the  LINE  ( vector")  mode  two  consecutive  points 
are  connected  with  a (bright  or  dark)  straight  line.  Only 
the  specification  of  the  brightness  and  one  terminal  point 
is  needed  as  the  drawing  beam  starts  at  the  previously 
reached  position. 

Special  layout  functions  for  INTKRPOLation  (4)  and  for 
the  drawing  of  arcs  of  CIRCLES  (5)  may  be  useful. 


Fig.  5 

Example  of  a vector 
(LINE)  mode  display 


Fig.  6 

Example  of  an 
INTER  POLated 
curve  and  an 
arc  of  a CIRCLE 


Examples : 

I)  X (1)  : 10;  X (2)  ; = 20;  X (3)  ; 30;  Y (1 ) : 40 ; Y (2)  : 10 ; Y (3)  : 20; 

OUTGRAPHIC  (DISPLAY,  (X,Y),  RANDOM); 


3)  STAR  : ((10. 10,  '0'BI, 

(20,20.  T'B), 
(30,10,  T'B), 
(20,30.  ’0'B), 
(20,  ->0,  i B)); 
OUTGRAPHIC  (DISPLAY, 
STAR.  LINE): 


/ 

* 
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5. 2. 4. 2.  The  Input  Procedure  INGRAPHIC 
Syntax : 

INGRAPHIC  (external-terminal,  internal -terminal, 
function  (par, ...)); 

Semantics : 

external-terminal  is  a graphic  input  device  like  a Bghtpen 
or  a joystick  that  has  been  described  in  the  system-di- 
vision  of  the  program.  Usually  internal-terminal  is  a 
pair  o(  variables  (x,  y),  and  there  is  no  3rd  parameter. 
The  input  device  supplies  coordinates  which  are  stored 
in  x and  y.  INGRAPHIC  allows  the  identification  of  cer- 
tain points  on  the  image  on  a graphic  output  device. 
According  to  that  identification  further  actions  can  be 
taken  in  the  program. 


5.2.5.  Calibrated  Input /'Output 

These  procedures  are  useful  for  transferring  analog 
information  supplied  by  a process  input  device;  during 
output  the  user  is  able  to  specify  an  angle  e.  g.  in  units 
of  degres  instead  of  a number  of  steps  a motor  has  to 
turn. 

5. 2. 5.1.  The  Input  Procedure  INCALIBRATED 

Syntax 

INCALIBRATED  (external-terminal,  internal -terminal. 

calibration-function  (par, ...)); 

Semantics : 

The  external  device  supplies  one  or  more  analog  test 
values  that  are  stored  in  working  storage  in  a digitalized 
and  calibrated  form  (transformed  into  physical  units). 
This  is  accomplished  by  a calibration-function  that  is 
part  of  the  system  library,  the  parameters  of  which  can 
be  supplied  by  the  programmer.  E.g.  one  can  use  a poly- 
nomial to  calibrate  the  input  values  delivered  by  a ther- 
mocouple. When  the  element  is  replaced  this  can  be 
taken  into  account  merely  by  changing  the  coefficients  of 
'he  polynomial  ( = parameters  of  the  calibration-function). 

5. 2. 5. 2.  Output  using  OUTC  A LIBRAT ED 
Syntax : 

OUTC  A LI  BRAT  ED  (external-terminal,  internal-terminal, 
calibration-function  (par, ...)); 

Semantics ; 

internal -terminal  contains  variables  that  specify  the 
amount  in  physical  units  by  which  the  position  of  a ter- 
minal device  (e.  g.  a valve  using  servo  motors)  has  to 
be  changed. 

Example : 


Comment:  The  calibration-procedures  must  be  prede- 
fined by  the  programming  system.  A linear  calibration 
function,  a polynomial  and  a nonlinear  calibration  using 
several  lists  seem  to  be  sufticient  for  the  most  appli- 
cations. 


5.2.6.  Input  and  Output  of  Control  Information 
Syntax : 

: OUTCONTROL  | , . . . ...  , . . 

INCONTROl  I (external-terminal,  internal-terminal) ; 

(In  the  case  of  OUTCONTROL  the  internal-terminal  may 
also  be  a constant  - generally  BINAL) 

Semantics : 

INCONTROL  stores  the  status  information  (as  far  as  it 
is  relevant  to  the  system)  of  the  addressed  peripheral 
into  the  named  variables.  Using  OUTCONTROL  control 
commands  can  be  sent  to  peripheral  devices. 

Range  of  application: 

INCONTROL  mainly  will  be  used  to  check  functions  of 
process  peripherals;  this  procedure  is  a means  of  ma- 
chine-oriented programming.  In  a similar  manner 
OUTCONTROL  .3  used  if  one  wants  to  deal  with  details 
of  the  I/O-hardware  (as  it  can  be  done  using  assembler 
language). 

The  features  of  CONTROL  I/O  are  similar  to  that  of 
PRIMITIVE  1^0;  but  here  only  control  information  - no 
data  - is  exchanged. 

Example : 

ON  INTERRUPT  SENSOR  1 BEGIN 

INCONTROL  (SENSOR  1 , X) ; 

IF  X = '00110010' B THEN  GO  TO  ALARM  FI 
END; 


5.3.  Auxiliary  Procedures  for  Input/Output 

To  accomplish  complex  control  functions  in  the  1/0-ma- 
nagement  of  the  system  a number  of  standard  procedures 
are  available. 

These  are  procedures  for  OPEN-ing  and  CLOS-ing  1/0 
which  can  also  act  on  files,  for  reserving  a device  for 
exclusive  use  (LOCK)  and  for  cancelling  the  reserva- 
tion (UNLOCK),  for  RESET-ting  a device  and  for  SET- 
ting  it  to  a specified  state  and  for  STOP-ping  1/0  ab- 
ruptedly.  Functions  to  CREATE,  to  REIDENTify  and  to 
SCRATCH  (i.  e.  to  cancel  the  reservation)  files  are  also 
necessary.  There  must  be  also  a number  of  formatcon- 
trolling procedures  (to  be  used  as  subparameters  of 
FORMAT  or  layout -procedures  or  as  stand-alone  calls), 
e.g.  BACKSPACE,  SKIP,  NEWLINE,  and  NEWPAGE. 


OUTC  A LIBRAT  ED  (MOTOR  1 . FLOW,  CALIB1  (Al,  A2,  A3)) 

• THE  FLOW'  THROUGH  A PIPELINE  IS  REDUCED  TO  A CERTAIN  VALUE; 
THE  RELATION  BETWEEN  THE  POSITION  OF  THE  VALVE  AND  THE  VALUE 
OF  THE  FIX1W  IS  NONLINEAR  AND  DESCRIBED  BY  FUNCTION  'CALIB  1’  */; 
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LAI 


- INTRODUCTION  - 

The  LAT  language  has  been  developed  as  the  result  of  the 
search  for  new  means  of  programming  industrial  applications 
so  as  to  diminish  the  overall  cost. 

The  workhas  been  financed  by  an  assembly  of  users  (DGRST) 
with  Government  funds. 

The  resulting  specifications  summarized  below,  are  the  work 
of  six  people  who  used  the  Purdue  Workshop  LTPI.  Committ  e 
specifications  as  a guide  line  and  who  evaluated  a number 
of  existing  languages. 

PL/ I or  Fortran  programers  must  find  it  particularly  easy 
to  learn,  but  it  is  not  thought  that  a subset  of  PL/I  would 
meet  all  the  functional  requirements  .'Therefore  , the  langua- 
ge strives,  where  possible,  to  resemble  PL/ 1 and/or  Fortran. 

LAI 1 s principal  caracteristics  are  : 

- machine-independance , allowing  the  re-use  of  programs, 
changing  computers,  package -imp  lenient  a t ion  . 

- real-time  language.  The  language  is  coupled  to  a standard 
supervisor,  written  in  the  language  and  includes  the 
concepts  of  events,  semaphores,  tasks,  in te rr up t -hand  1 ing 
so  as  to  solve  specific  real-time  industrial  applications 
problems . 

- fixed-point  and  floating-point  arithmetic. 

- bit  and  bit-string  handling. 

- data  packing  and  unpacking. 

- formalization  of  industrial  input-output. 


- DATA  TYPES  - 

2.1.-  Ar i thme  tic  data  - 

- Integer  variables.  Attribute  : maximum  absolute  value 

- Integer  constants.  Attribute  : none 

- Unsigned  integer  variables.  Attribute  : maximum  abso- 
lute value 

- Unsigned  integer  constants.  Attribute  : none 
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- Fixed-point  variables.  Attributes  : maximum  absolute 
value  and  precision 

- Fixed-point  constants.  Attribute  : precision 

- Real  variables.  Attribute  : number  of  decimal  digits 
for  the  representation  of  the  mantissa 

- Real  constants  . Attribute:  number  of  decimal  digits 
for  the  representation  of  the  mantissa. 

2.2.-  String  data  - 

- Bit-string  variables.  Attribute  : length  of  the  string 

number  of  bits 

- Bit-string  constant.  External  representation  :binary, 
octal  or  hexadecimal 

- Caracter-s tring  variables.  Attributes  : s t r ing- 1 ength: 
and  associated  code 

- Caracter-s tring  constants.  Attribute  : associated  code 

- Sub-strings  are  declarable  (static  attributes) 

- PART  pseudo-variable  : sub-string  definition  with 
dynamic  attributes. 


3.-  DATA  AGGREGATES  - 


- Arrays 

: aggregate  of  data  of  the  same  type  with  the 
same  attributes . 

- Structures 

: aggregate  of  data  of  anay  type  and  attributes. 
All  data  (including  eventually  arrays)  declared 
in  a structure  are  packed  in  memory.  Structures 
will  often  be  used  in  structure  arrays. 

4.-  OVERLAY  - 

The  overlay  declaration  allows  the  same  memory  space  to  be 
affected  to  several  data  or  data  aggregates,  whose  attributes 
may  be  different. 


5 . - EXPRESSIONS  - 

The  operands  may  be  integer,  unsigned  integer,  fixed-point, 
real,  bit-str'ng  or  single  caracter.  In  the  case  of  bit 
strings  and  single  caracters,  a conversion  to  unsigned  inte- 
ger is  implicit.  All  classic  arithmetic  operations  are  al- 
lowed : addition,  subtraction,  multiplication,  division, 

exponentiation. 

Conversions  between  arithmetic  types  are  implicit  in  the 
following  order  of  increasing  priority  : unsigned  integer, 
integer,  fixed-point,  real.  Explicit  conversion  functions 
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- Logical_or_bit-string_exgressions 

Boolean  expressions  are  a particular  case  of  logical  expres- 
sions. The  operators  are  : negation,  intersection,  union, 
disjunction.  Comparisons  give  boolean  or  logical  primaries. 


6.-  INSTRUCTIONS  - 

“ Assignment  (with  implicit  conversion) 

- GO_TO 

- Comgut ed_GO_TO 

- Subgr ogr am_ca 1 1 : subprogram  name  followed  by  parameters 

and  possible  return  addresses  between  parentheses 

- RETURN  : dynamic  (run-time)  end  of  a subprogram,  an  interrup 

procedure,  a function  or  a task 

- Cond i t iona l_i ns t rue t ion  : it  can  have  two  forms  : 

Form  1 : 

IF  logical  expression  THEN  unconditional  instruction  ELSE 
unconditional  instruction 

Form  2 : 

IF  logical  expression  THEN  unconditional  instruction 

Any  other  instruction  is  of  unconditional  type  (e.g.a.  com- 
pound instruction). 

“ : its  form  is  : 

DO  variable  name  - initial  value  UNTIL  maximum  STEP  value  ; 

; body  of  the  iteration 

e'nDDO  ; 

- Comgound_ ins  true t ion  : it  is  made  up  of  a number  of  instruc- 
tions enclosed  between  DO  and  ENDDO  ; 

- Sugeryisorinstructions  : they  are  detailed  in  paragraph  8 


7 .-  PROGRAM  STRUCTURE  - 

A program  is  made  up  of  a number  of  articles.  There  can  be 

the  following  types  of  articles  : 

- globa l_da t a_a r t ic le  : this  article  contains  only  the  de- 

clarations of  data  common  to  several  modules  (a  module  is 
a separately  compilable  unit).  Any  other  article  referen- 
cing these  global  data  must  declare  them  with  the  EXTERNAL 
attribute. 

- subgrogr am_ar t ic le  : it  is  the  classic  notion  of  subpro- 
gram. It  can  have  the  attribute  REENTRANT.  The  arguments 
are  passed  by  value  (default  option)  or  by  address.  The 
subprogram  may  return  values  to  the  invoking  program. 
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Several  return  addresses  may  be  specified,  the  RETURN,  end 
of  the  subprogram,  being  fo 'loved  by  a computed  value 
which  enables  the  selection  of  the  return  address  in  the 
list. 

The  subprogram's  formal  parameters  have  a presentation 
which  is  identical  to  declarations. 

_ fyD££i2Q_5E.ti£±§  : it  has  a form  identical  to  the  subpro- 

gram but  with  an  attribute  which  gives  the  result's  data 
type  . 

- interrugt_procedure_ article  : each  interrupt  procedure  is 

attached  to  a hardware  interrupt  by  an  ON  statement. 

The  interrupt  procedures  have  no  parameters  and  cannot  con- 
tain any  supervisor  instructions  which  could  place  them 
in  a suspended  state.  They  may  create  tasks  and  activate 
events  . 

- process  article  : the  process  is  that  program  unit  whose 

execution  (including  the  subprograms  it  invokes)  will 
constitute  a task.  It  is  managed  by  the  supervisor.  The 
processes  cannot  be  reentrant,  i.e,  at  any  time,  there 
can  only  be  one  task  attached  to  each  process.  There  is  a 
waiting  list  attached  to  each  process  for  storing  task 
creation  requests  when  a task  already  exists. 

A static  priority  level  is  associated  to  each  process  ; 
this  will  be  the  priority  of  the  task  created  unless  a 
dynamic  priority  is  specified  at  the  time  of  creation. 

A process  may  have  parameters,  passed  by  value  or  by  ad- 
dress; 

One  process  will  be  qualified  for  general  initialisation 
by  use  of  the  key-word  START. 


8.-  LANGUAGE -SUPERVISOR  RELATIONS  - 
8.1.“  Events- s emaphores  - 

The  supervisor  manages  the  system  resources  by  the 
use  of  operators  applied  to  two  particular  data  types 
in  the  limits  specified  by  the  programer. 

- Even's 

These  are  booleans  manage  d by  the  supervisor.  EVENT 
type  variables  may  have  one  of  two  values,  SET  or 
RESET,  controlled  by  the  orders  ACTIVATE  and  ERASE. 

The  instruction  WAIT  "event  expression"  allows  the 
user  to  specify  the  conditions  under  which  the  wai- 
ting task  can  again  be  eligible.  The  event  expression 
can  contain  event  type  variables  and  times,  connected 
• by  the  logical  operators  AND,  OR. 
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- Semaghores 

The  semaphore  variables  and  t I . r associated  operators 
RESERVE,  FREE  allow  the  user  to  program  me  management 
of  resources  common  to  several  tasks  (data-access, 
programs,  peripherals...).  The  execution  of  these 
operators  by  tne  supervisor  is  uninterruptible. 

A counter  is  associated  to  each  semaphore  ; its  ini- 
tial value  is  given  by  the  declaration.  The  counter 
is  incremented  by  a value  n by  the  operator  FREE  with 
the  parameter  n and  decremented  by  a value  m by  the 
operator  RESERVE  with  the  parameter  m.  The  decrementa- 
tion takes  place  only  if  the  counter's  value  after 
decrementation  is  not  negative  ; otherwise,  the  coun- 
ter's value  is  unchanged  and  the  invoking  task  is 
suspended. 

8.2.-  Task  management  - 

A task  is  created  by  invoking  the  corresponding  pro- 
cess. If  a task  was  already  created  for  that  process, 
the  call  is  placed  in  the  attached  waiting  list. 

The  execution  of  the  RETURN  instruction  in  a process 
ends  the  associated  task. 

A task  may  be  created  either  by  another  task  or  during 
the  execution  of  an  interrupt  procedure. 

The  supervisor's  scheduler  gives  C^U  control  to  the 
highest  priority  task  immediately  after  a task  crea- 
tion or  at  the  end  of  an  interrupt  procedure.  The 
scheduler  also  gives  control  to  the  highest  priority 
eligible  task  every  time  a supervisor  operator  is 
executed  which  can  change  the  eligibility  of  the  cur- 
rent tasks  . 

A task  may  be  suspended  by  the  instructions  WAIT, 
RESERVE,  INPUT,  OUTPUT  and  after  creation  of  a higher 
priority  task  or  if  a higher  priority  task  oecomes 
eligible. 

The  instruction  STOP  suspends  unconditionally  the 
task  associated  to  the  process  whose  name  is  given. 

The  instruction  GO  renders  it  eligible  again. 

Any  task  may  be  interrupted  by  an  interrupt  ; it 
willr.egain  control  after  the  interrupt  procedure 
has  been  executed,  unless  a higher  priority  task  has 
been  created  or  rendered  eligible  in  the  procedure. 
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8.3.~  Interrupt  control  - 


The  interrupt  control  instructions  allow  the  connec- 
tion of  an  interrupt  procedure  to  an  interrupt  level, 
to  enable,  disable,  arm,  disarm  any  interrupt  level. 

The  instruction  WAKE  (delayed  software  interrupt)  will 
cause  the  execution  of  an  interrupt  procedure  after  a 
given  time  has  elapsed- 

8.4.-  Input  - output  - 


Standard  input  ~ output  (computing  - center  peripherals) 
are  separated  from  industrial  input-output  peripherals. 

~ §£ tgut 

The  I/O  instructions  reference  formats  not  unlike 
Fortran's  and  can  be  executed  with  or  without  wait. 

If  executed  without  wait,  an  event  can  be  associated 
to  the  I/O  ; this  will  be  activated  by  the  supervisor 
at  the  end  of  the  I/O. 

An  attempt  of  formalization  of  industrial  I/O  has  been 
made.  The  I/O  by  canal  and  those  by  programed  link 
are  distinguished.  In  both  cases,  all  of  the  parameters 
of  the  I/O  instruction  and  the  associated  peripheral 
declaration  are  programed  in  a machine-independant  way. 

This  is  a point  which  will  be  completely  determined 
only  after  the  first  implementations. 


9.-  COMPILATION  METHOD  - 


The  method  of  compilation  is  given  on  the  following  figure. 
The  compiler  has  been  evaluated  at  about  120  k bytes. 


am 


The  COMPILER  and  TRANSLATOR  blocks  are  machine-independant 
The  macro-definitions  must  be  renewed  for  every  object-machine 

The  interpreter  allows  a good  debugging 

The  operator  does  not  need  to  know  the  intermediate  language 
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ELEMENTARY  DESCRIPTION  OF  THE 
FEATURES  OF  THE  PROCOL  LANGUAGE 


LTPL  EUROPEAN  GROUP 
LTPLE  / 016 


Categories  : I , D 
Update  none 
Obsolete  none 
5 PP 


Introduction 

The  purpose  of  this  note  is  to  present  the  main  features  of  the  PROCOL 
Language  in  the  same  manner  as  it  was  done  in  Appendix  A of  the  minute 
of  the  2nd  meeting  in  Paris  (March  16-17  - 1971)- 

PROCOL  has  been  developed  on  the  initiative  of  the  Automation  Commitee 
of  the  D.G.R.S.T.  * and  this  was  decided  after  a census  of  the  fonc- 
tional  requirements  has  been  done. 

It  appears  like  a general  language  for  Real  Time  applications. 

A first  implementation  of  PROCOL  is  being  done  on  the  T 2000  of 
LA  TEI£MECANIQ,UE  and  is  composed  of  four  parts  which  will  not  be  des- 
cribed in  details  here  : 

1 An  executive  system  PREX 

2 A compiler  PROC 

3 A system  generator  PROG 

4 A loader  PROL 
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1.1  - Basic  Language  Structure 


Language-  Character  set 


Set  of  ASCII  characters 


A,  B,  Z 


0,  1, 


SP  ! " ti-  $ % £ ' ( ) x + - , 


Delimiters 


Operator 

Parentheses 

Keywords 


Identifier 


A letter  followed  by  up  to  5 letters  or  digits  only. 


Keywords 


reserved 


Comments  - enclosed  by  ' and 
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1.2  - Basic  Programme  Structure 


Program  ( programmed  application  ) 


A programmed  application  is  a collection  of  elements  ; 
an  element  may  be  : 

- Common 

- External  sub-programs  (re-entrant) 

- Task  (composed  of  the -task  itself  and  eventually  of  internal 
sub-programs) 


Simple  statement 
N0*  Compound  statement 

N^Bloc  Structure 

2.1  - DATA  ORGANISATION 

a . Scalar  data 

b . Arrays 

c.  Structures  (packed  information  on  one  word) 

d.  Arrays  of  Structures 

2.2  - NAMING 


a.  Simple  name 

b.  Subscripted  name 

c.  Qualified  name 

d.  Subscripted  qualified  name. 


V 
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2.3  - DATA  TYPES 

a/  Problem  data 

Integer  with  sign  (one  word) 

Real  with  sign  (two  words) 

Binary  (may  be  scaled  by  a scale  factor) 

Short  integer  (T20C0) 

Structure  (data  whose  length  is  one  word  and  which  can  be  sliced  into 
parts  : items,  there  items  may  overlap  each  other  within  the  structure 
Items  corresponding  to  such  structures. 

Arrays  of  each  mode  in  one,  two  or  three  dimensions. 


b/  Program  control  data 


DATA  declaration 

-Common  declarations  wnich  include 'I/O  declaration 

' FORMAT  declaration 


- Sub  programs  declaration  (External  subroutine  or  Functions) 


SUBROUTINE  (or  FUNCTION) 
- Task  declaration  ' PROCEDURE 


i MAIN 


2.4  - EXECUTABLE  STATED  UTS 


Assignment  statement 
GO  TO  statement 

Switch  statement 

DO  statement 

Conditional  statement 
Subroutine  statement 
Function  statement 
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return  statement 

Code  insei'tion  statement 

Task  handling  statements 

Timers  handling  statements 

Pulses  counter  handling  statements 

Interrups  and  Events  handling  statements 

Semaphores  handling  statements 

3.1  - SCALAR  EXPRESSIONS 

a/  Arithmetic  Operations 
addition 
subtraction 
multiplication 
normal  division 
exponentiation 

b/  Bit  string  operations 
conjunction 
union 

disjunction 

c/  Comparison  operations 

= (Different)  ~ <3  3,  3 = 

d/  Address  Operands 

- none  - 

e/  Data  conversion 
implicit 

4.1  - DATA  DESCRIPTION-DECLARATION 

The  declarations  are  explicit. 

A declaration  is  static  arid  its  rangeis  the  'place'  where  it  is 

made  vhere  'place'  may  means  : task,  sub-programms,  functions  and 

subroutines .Data  in  common  Has  a global  scope. 


\ 
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PROCOL  : TASKING 


1)  Definition 


A task  is  a set  composed  by  a program  and  eventually  subprogramm, 
the  run  of  which  performs  a certain  function  for  the  user. 

A task  has  some  characteristics  defined  at  the  generation  of  the 
system. 

. A name 

. A priority  which  can  be  of  hardware  level 
or  of  software  level 


2)  Restrictions 


A task  is  not  reentrant 

A task,  when  running,  must  be  entirely  resident  in  one  piece  in  core 
memory 

A task  must  be  executed  from  the  same  address  (T.2000  option) 

3)  States  of  a task 


a)  active.  . 

tiie  task  is  in  the  queue  corresponding  to  its  own  priority  and  is 
given  the  control  when  all  its  predecessors  have  left  the  queue. 

b)  CANCELLED 

the  task  is  suppressed  from  the  queue  where  it  was  waiting  for  its 
turn  of  having  the  control.  This  cancellation  may  be  ordered  from 


another  task. 


4 
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If 


c)  TERMINATED 

the  task  is  normally  terminated  and  control  is  given  back  to  the 
monitar 

d)  WATTING 

the  task  is  interrupted  (itself)  and  is  waiting  for  an  (or  a 
sequence  of)  events 

4)  Task  Scheduling 

Among  all  the  task  present  at  the  same  time  in  core  memory,  the 
user  has  the  possibility  that  not  two  tasks  may  be  executed  at 
the  same  time. 

Two  levels  of  scheduling. 

'Hardware'  tasks  are-  scheduled  at  hardware  level 
'Software'  tasks  are  scheduled  at  software  level. 

5)  Task  synchronization 

the  tasks  use  two  types  of  ressources  : 

1 : physical  ressources  : processor,  core  memory.... 

2 : logical  ressources  . external  sub- programs. 

The  executive  PREX  has  to  solve  all  kind  of  conflits. 

Each  ressource  is  assigned  a semaphore  ; tasks  may  ask  for  the 
ressource  tlirough  the  instruction  : 


semaphore  is  set  up  to  the  busy  state.  If  the  ressource  is  busy, 
the  task  enters  the  queue  of  the  semaphore  SEM  (i). 


When  the  task  has  finished  to  use  the  ressource,  it  use  the  instruction  - 

RELEASE  SEM ( i ) Which  frees  the  ressource  and  allows  one  of  the  task 
of  the  queue  to  access  the  ressource 

* 

Nota  : the  user  may  associate  a semaphore  to  a virtual  processor  : 

when  the  semaphore  is  busy  none  of  the  task  using  this  virtual 
processor  could  be  activated. 

\ 
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PROCOL  : INPUT  / OUTFUT 


A distinction  has  been  made  in  PROCOL  between  classical  and  industrial 
input/output 

1 * .Classical  I/O 
As  in  FORTRAN 

2°_ .Industrial  I/O 

The  user  has  the  possibility  to  refer  symbolically  by  an  unique  iden- 
tifier to  an  industrial  peripheral  or  a part  of  it. 

a)  General  format  of  the  instruction 

ORDER  ((peripheral) , ( format),  ^complementary  information")  'list 

of  variables . 

b)  Execution 

- in  input  : read  the  information  on  the  peripheral,  following  the  in- 
dications of  the  format  and  transfert  into  the  data  zone  named  in 
the  list. 

- in  output  : transfert  of  the  information  from  the  variable  to  the 
peripheral  according  to  specified  formats. 
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c)  Description  of  i/o  in  the  COMMON  part 

- i/o  description 

type  ; ana. ogle,  digital,  input,  output,  special 
number  of  module  using- th  d ."in  1 type 
specification  of  channels  of  the  'is  1 r.  duit 
name  assigned  to  the  described  i/o  unit  by  the  user 

- format  description 
different  field 
check  on  now  measures 
filtering 

linearization,  conversion 
check  on  logical  information. 

There  is  the  possibility  t add  new  types  ol  I /(  (type  ). 
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PROCOL  : TIMERS  HANDLING 


The  user  is  allowed  to  handle  a certain  number  of  TIMERS. 

A timer  has  a name  and  a step  ; This  is  declared  by  '/TIMER'  when  gene- 
rating the  system. 

Ins tructions 

START  : initializes  the  timer  and  sets  up  its  value  to  zero 
STOP  : stops  the  timer. 

AFTER  : asks  for  the  execution  of  a particular  job  after  a 
certain  number  of  step  of  the  timer. 

EVERY  : asks  periodically  for  the  execution  of  a particular  job. 
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WORKING  PAPER 


INDUSTRIAL  INPUT  - OUTPUT 
in  PROCOL 


Procol  has  facilities  for  peripheral  description  which  allow  the 
user  to  refer  to  partafor  the  whole  peripueral  by  only  one  identifier 
(which  may  be  an  array) . For  exemple  : one  or  several  channels  in  a 
analogic  module  may  be  refered  by  one  identifier. 


1/  Types  of  industrial  Input/output 
There  are  8 types  of  input-output  : 


ANIN 

: analogic 

input  module 

ANOUT 

• ft 

output 

DIGOUT 

: digital 

ii 

DIGIN 

. I? 

input 

TSIN 

: transfer 

station  input 

TSOUT 

SEQUIN 

SEQU0UT 

• tt 

" output 

An  industrial  unit  is  a set  channel-module  to  which  the  user 
gives  a name. 

2/  Description  of  industrial  units 

ANIN  (3)  CHANNEL  (5)  TEMP  1,  CHANNEL  (A(12  : 25))  TEMP2 
ANIN  (5)  CHANNEL  (I  : 8)  PRESSURE  ; 

DIGOUT  (7)  CHANNEL  (J)  DEBIT  ; 

The  table  A has  been  defined  in  the  COMMON  part. 


3/  Description  of  the  formats 


Application 


->! 


transformation 


FORMAT 


industrial 

peripherals 


logical  informal  ion 

T 


checks 

J L_ 


physical  information 

J 


k 
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An  Indus t riel  1/0  Pi-oloI  will  con Lain  a certain  quantity  of  informa- 
tion which  allow  th«  run^cmvai ion  01  a logical  information  into  a 
physical  information  ana  vice-versa.  This  transformation  will  be 
accompanied  Li  various  chocks  on  ,.c-  validity  of  the  informations. 
For  example  : an  ana  ic  teed.!  steps  : 

i)  measure  : - get  tilt.  Uv.  raw  mesure  (physical  information) 

- check  of  .1-  mesure  validity 

- filtering 


ii)  linearization-conversion  : from  the  rat;  mesure  to  the  corrected 

measure  (user) 


iii)  check  of  the  corre  w_-d  measure 


Example  : 

10  : I FORMAT  PIIYSCHECK  ST  (a,  b,  SP1  (REPORT,  PARAMETER;), 
FILTER  LT  (15), 

COW  SP2  (L3T,  BUF.  parameters), 

LOGCHECK  BT  (A,  SP5,  (LSI ) : B,  SPA  (LST) ) ; 


C FORMAT  > 


<.  identification  area  > <.  control  on  physical  information') 

< filtering  of  physical  Informa  ion> ^linearization-con- 
version 


< control  on  logical  information  / 


i ) Identification  a re- 

- adress  of  the  format 

- input  or  output 

i L ) Control  on  physical  Informs ; i on 

physical  information  : - information  send  to  (from)  t.he  converter 

in  input  : the  raw  measure 

in  output  : the  value  to  be  displayed 

The  user  has  two  possibill ties  for  the  check  on  the  physical 
information  : 


\ 


vACU  * - » 


V/ 
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1 - standard  Option 

th  value  is  compared  with  the  two  bounds  min  and  max 
PHYSCHECK  ST  (min,  max,  SFE  (REPORT,  — ))  , 

2 - Non-standard  option 

trie  user  specify  nis  proper  processing  by  means  of  a subroutine 
(SPE) 

PHYSCHECK  SPE  (LST  parameters,  REPORT,  -) 

In  both  cases  trie  REPORT  option  reports  on  any  misfonctionnement 
and  the  user  can  pursue  or  not  the  interpretation  of  the 
format,. 

Note  REPORT  : = <"  Symbolic  unit  number  > 

< Identification  of  the  channel  which  has  created 
the  overpass  on  a boud  > 

x Pick  up  ox'  transmitter  unavailability  ) 


iii ) Filtering  of  the  physical  information 

The  user  has  here  two  possibilities  standard  (a)  ana  non-stan- 
dard (b) 

a)  FILTER  ( G ) 

( L ) (n) 

( B ) 


n 


L 

B 


rate 

the  rat.  measure  must  remain  greater  than  (1  - n •)  ,m 
where  m is  cue  value  of  the  most  recent  measure' . 

" " " loss  than  (1  + n;,:).m 

" " " bctv.’een  (1  - n,().m  and 

(1  + n , ,m 


b)  Tne  non- standard  option  allows  the  user  to  specify  nis  own 
mode  oi  f Uterine  by  means  of  another  subroutine. 


FILTER  SPE  (LST  oarameters) 


iv ) Linearisation  --  cunv ■■•rsicii 


This  transformation  is  o be  made  by  the  user  oy  moans  of  a 
subroutine 

CONV  SPE  (1ST  oarame  to : .. ) 


v)  Cheek  of  the  io,  i- ai  :ni ornu  nlon 
The  user  has  two  possibili ties  : 


a/  standard  ooiion  • 

( G 

L0GCHECK  < L ) (bound  , SPEp, 

( B ) 


(...))  » 


’em'  means  : corrected  measure 


G : 

bounu,  > boundp 

- 

cm  > bound. 

nothing, 

- 

bounUg  < cm  < boundp 

execute 

SPE^ 

- 

cm  < boundp 

execute 

SPEp 

L 

bound ^ C boundp 

- 

cm  < boundp 

nothing, 

- 

bound,  <cm  < boundp  : 

execute 

SPE] 

- 

cm  boundp  : 

execute 

QpTV 

B 

bound,  C bound- 

X cL 

- 

cm  < boundp 

execute 

SPE, 

1 

- 

cm  > boundp  : 

execute 

SPhp 

- 

boundp  <cm  l boundp 

b/  Non  standar  ■ option  •. 

Tlie  user  may  sreoit':  ' • treatemeni  • means  of  a subroutine 
LOGCHECK  SPE  (LST  parameter)  ; 


V Industrial  Input -Ou  out  Inc ‘ rat  ions 


- : ra 


( INPUT  ), 
( OUTPUTS 


< Industrial  unit  > , < f 

f j: means  optional 


number  > <( 


complementary v j ^ 
information 


List  of  variables 


/ 
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4.2  - Analogic  Input-0u\ pu 

a/  singl  :■  : INPUT  (TEMP  1,  n)  ALP  ; 

acquisition  from  tP.e  industrial  unit  TEMP  1 under  format  number 
n and  assignment  to  ALP 

b/  groui  dng  : INPUT  (PRESSION,  K)  TABLE  (10  : 17)  ; 

acquisition  from  the  8 channels  of  the  industrial  unit  PRESSION 
under  format  number  K and  assignment  of  these  8 measures  in 
TABLE  (10),  ---,  TABLE  (17) 

c/  complementary  information 
there  is  different  options  : 

i)  GAIN  of  the  converteur  : RANGE  ^constant  or  integer  ' 

variable 

ii)  FILTERING  : FILTER  <p'  'cedent  measure) 

by  default  there  is  a standard  treatment. 


4.(5  - Digital  Input-Output 

There  is  no  format  used 

a/  single  : industrial  unit  = 1 channel  of  a digital  module 

list  of  variables  = 1 variable  : item  or  table  of  bi* 

INPUT  (CLE  ) ALPHA  (J)  ; 

CLE  is  for  example  channel  n°  ) 

ALPHA  (J)  is  the  j n element  in  a table  of  bius 

b/  grouping  : industrial  unit  = m channels  from  a digital  module 
variable  = word,  structure,  implicit  loop  of  table 
of  1 oit  item. 

INPUT  (CLES)  BIT  (5:8); 


\ 
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WORKING  Pa  PER 


TASKING 


IN  PROCOL 


In  this  section  we  refer  to  the  "Tasking  Facilities"  part  of  the  paper 
from  LTPLA,  numbered  X3Jl.^-27* 

The  states  idle  and  dormant  are  not  separated  in  PROCOL,  because  once  a 
task  has  been  created,  a segment  and  a data  area  are  assigned  to  it. 

The  other  states  are  approximateley  the  same  in  Procol. 

The  most  important  new  tasking  feature  appearing  in  Procol  is  the 
distinction  between  Softare  Tasks  and  Hardware  Tasks. 

They  are  all  declared  iri  the  same  manner  at  the  generation  of  the 
system. 
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TASKING  I 


■ 


1 . Dei inition 


f 

t 

k 


A task  is  a set  composed  by  : 

- a program 

- and  eventually  subprograms 

the  run  of  wl  ' . performs  a certain  function  for  the  user. 

2.  Task  general. lor 

A task  is  generated  in  the  fallowing  manner  : 

/TASK 

<"taskname  1 > : 1 priority-nunber3  C,  residence  optional  T,  SEM 
(number )j  where  : 

taskname  is  the  identifier  of  the  task  . 
priority -number  : 

residence-option  may  be  ; resident  incore  memory  or  net  resident 
(number)is  a number  assigned  uniquely  for  each  task  and  is  used  for  the 
control  semaphore  . 

. Characteristics  of  a tas* 


- Its  name . 

- Its  priority  which  car.  >e  :>l  hardware  level  or  of  software  level 

- An  attribute  for  its  residence . 

a/  Cor.di  .ions  lot  execution  ct  a ;,asx 

The  central  unit  is  considered  as  a shared  ressource  for  the  tasks  . 
The  user  has  the  possibility  to  define  which  set  of  tasls  will  be 
sharing  the  C.P.U  ; 

he  may  decide  that  a task  will  not  started  if  another  task  of  the 
same  set  is  running. 


\ 
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The  user  may  specify  the  condition  of  preemption  of  a task  by  another 
with  higher  priority  : 

. left  task  : the  task  will  be  restarted  only  by  an  activation 
. saved  task  : restarded  from  the  point  of  interruption 


4.  Task  operation 


- ACTIVATE  Tasknarae  : the  task  is  placed  in  the  queue  of  the  awaiting 

task  for  execution,  according  to  its  priority. 
If  taskname  has  a nigher  priority,  it  preempts 
the  task  in  execution. 


the  are  two  kinds  of  activation  : conditionnal  and  inconditionnal. 


- CANCEL  Taskname  : suppression  of  taskname  from  the  queue 

- EXIT  : the  task  in  execution  is  ended. 


- WAIT  : the  task  is  interrupted  and  waits  untill  the 

wait  appears. 


FUNCTIONS  FOR  SOFTWARE  TASKS 


FUNCTIONAL 

OPERATION 


STATE  CHANGE  OF 
OBJECT  TASK 


ARGUMENT 

REQUIRED 


GENERATION 


CREATE 


0 — > 2 


SYSTEM 

CANCEL 

EXTERMINATE 

ACTIONS 

READY 

RUN 

PREEMPT 

INHIBIT 

UNSUSPSND 

2,3,4, 6-  , 2 or  5 

< TASK  ' 

can  be  done 

< TASK  a> 

5 -O 

v.  TASK  > 

3 6 

<.  TASK  > 

6 — >3 

^ TASK  > 

4 

< TASK  > 

SELF 

SCHEDULEME 

ACTIONS 

MYSTATUS 

scheduled 

exit 

6 - >■  2 or  5 

DELAYME 

6 — 4 

WAIT 

6 — > 4 

SECURE 

6 — 4 or  6 

1 

[ 

! CANCEL  (EXECUTE) 

2 — - 3 

ACTIONS 

| SCHEDULE 

2 — 5 

ON 

CANCEL  (TERMINATE) 

6,3,4-12  or  5 

OTHERS  SOFT 

J RELEASE 

4 — >3 

TASKS 

! SIGNAL 

4-'  3 

STATUS 

scheduled 

0 time/  seven • -»  , 
^ TASK  > 

/TOPS>  < TIM  (n)/1 
< even t>' tops > , 

semaphore > 


/tops'  < TIM  (n;'i 
: e < timeV/^event; 
^semaphore > 

, event  > 


There  are  not  the  following  functions  : exterminate 

delete 

Killme 

Delay  (another  task) 

Continue  (another  task) 

Kill 

suspend  (another  task) 

The  assigment  of  variable  priority  to  other  task  or  to  itself  is  not  allowed 


FUNCTIONS  FOR  HARDWARE  TASKS 


GENERATION 

CREATE 

0 — > 2 

SYSTEM 

RUN 

5 — > 6 

, ACTIONS 

1 

PREEMPT 

6 >3 

SELF 

MYSTAHJS 

ACTIONS 

EXIT 

6 >0 

ACTIONS 
ON  OTHER 
(SOFT)  TASKS 


EXECUTE 

SCHEDULE 

TERMINATE 

SIGNAL 

STATUS 


PRECEDING  PA^i  BLANK- i*>T  FILMED 
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WORKING  PAPER 
HARDWARE-SOFTWARE  LINKAGE 

IN  PROCOL 


D INTRODUCTION 

This  working  paper  describes  the  PROCOL  solution  for-  hardware-software 
linkage  (T  2000  implements;  ic-n J In  PROCOL,  the  user  generates  the  system 
means  cf  a convorn  ’ on  with  the  Program  Generator  : PROG. 


A "programmed  application"  is  composed  of  two  parts  : 

A set  of  'PRCCOL  i ns v.ru'  . ' ..o'1  corresponding  to  the  different  task.,  and  to 
be  translated  by  the  compiler  PROC. 

A set  of  "directives"  describing  the  hardware  configuration  and  the  softwar 
organization  to  PROG. 

2)  GENERAL  DuLCRIPflOH 

< programmed  application^  :=  <Cp.i.  -n.:t^>  . set.> 

< P. i.  set>  is  the  set  of  Procol  Instructions 

<D.  set  y :=  < COMPUTER  CONFIGURATION  > < APPLICATION  DESCRIPTION^ 

2.1.  “C COMPUTER  CONFIGURATION > : PHYSICAL  CONFIGURATION  < P.C.  QUERY  LISI> 


SYMBOLIC  CONFIGURATION  <S.C.  QUERY  LIST 


S 


UTILISATION  CHARACTERISTICS  <’  ,C.  QUERY  LI.  A/  {] 

The  mode  of  description  is  converse  .ionnal  and  is  expressed  by  a list  of 
queries  issued  by  the  system  generator  to  which  the  user  in  the  site  answers. 

a)  Physical  configuration  query  list 

List  of  priority  levels  for  i/o 

list  of  interrupts  levels  at  vrhich  task  , with  i/o  are  executing 
Bac  canal  i/o  list 


HlUMNiiMdh 


J 


a.l.)  Description  oi  classical  i/o 

- system  teletype* 

- other  dussical  peripherals  list 

- buffer  si.'e  (for  i/o  with  format) 

a. 2.)  Desc'i;tion  f industrial  peripherals 
-Digital  Input 

- Digital  Output  (grouped  or  not) 

- Analog  Input 

. Standard  (query  for  each  kind) 

. non  standard 

- Analog  Cutput  (query  for  each  kind) 

. Standard 
. Hon  standard 

b)  Symbolical  Corn 'irurat ion  Query  list 

Classical  .Symbolic  Unit  list 

Industrial  Symbolic  Unit  list 

Dir: in  modul  e 

cigout  module 

sequin  module 

sequout  module 

anin  module 

anout  module 

isin  module 

tsouc  module 

c)  Utilisation  characteristics 

- Industrial  formats  : Residence  Place,  size,  working  area  number 

- Conversion  Problems  for  Industrial  Formats 

- Different  other  uses  (Semaphores,  wait.  Every,  After,  Mask,  Signe1 


i 
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2.2.  < . / : < : lery  1 ..  t> 

Interrupts  Information  query  lint' 


: 'i  Task  Info.  ..ten  < u . y 1 in  ludes  questions  such  as 


Max  nunbt  r of  x : 
Names  of  t 


Mamas  oj. 


Names  of  . 
Dc. scrip ti  on 


. . . '.n*  casKs 


subroutine.-: 


Description  tf  time:  ...  puli 

1 err  upbore  .i  . .dlir 

Memory  djn  :.ri.<.  u nay  cent 


b;  Interrupts  V formation  query  list  includes  questions  such  as 


haxd*  rj  1 jvel 
event  level 
softwai  e 1 r.el 


?.~j.  f ic 1 1 . . i e a1  • ar. T 3 a . t 


k ) TASK  T ; 


There  ;a  .■  o'-'-.  qt'  ii  r ?or  madefying,  updating  ana  loading,  independ 


ot  o;t~  ap^.l:  2 ■ ' ■2.0  ~ 


p)  Ifii.U  I'ltv  \’0_  . ilFiil'il  'hS,  AMD  FORMATS  DESCRIPTION 


i/o  r ri oVar  ?.  . ...  >-  rrt  are  described  in  a the  COMMON  part  cf  the 
app! :'.c„l ion.  r nr  ./  .ie. .ar  of  special  declaration  instructions. 


/ \ V i '**1-  - 
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a)  i/o  peripheral  description 

This  has  been  detailed  in  LTPLE//J2A  : "INDUSTRIAL  INPUT/ OUTPUT  in  FROCOL" 
In  Procal  several  types  of  i/o  have  been  distinguished.  For  each  type  a 
keyword  has  been  assigned,  e.g.  "ANIN"  means  Analogic  Input  Module. 

The  user  has  the  possibility  to  address  by  a symbolic  name  all  or  part  . . 
of  a peripheral  devices  ; this  name  designate  an  industrial  unit. 

Each  industrial  unit  has  to  be  described  by  special  instruction  which  in- 
clude type,  device,  channel,  and  name  of  the  i.  unit.  A special  possibility 
of  FROCOL  is  to  designate  by  a single  name  a set  of  channels  of  a module 
whioh  are  not  necessary  consecutive. 

b)  j/o  foripat  description 
Desoribed  in  details  in  LTPLE/0^2  A 
4)  ADVANCES  OF  PRCCOL 

- The  separation  in  two  parts  yields  to  a better  efficiency  in  the  use  of 
the  machine  and  in  the  use  of  the  language  . 

- The  conversation  mode  for  describing  the  configuration  is  very  easy 
to  use  with,  in  some  cases,  pre-formated  answers. 

- In  case  of  changing  computer  and  its  environment  for  the  same  application, 
the  reprogramming  effort  is  only  limited  to  the  hardware  dependent  part. 

- The  possibility  to  handle  a specified  set  of  channels  in  a module  provide 
much  more  conveniency. 
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AUSTRAL  T A higher  procedural  language  for  use  with  the  Hitachi  control  computer 
SOU  has  been  developed  at  Hitachi  and  named  Process  Control  language  PCI  The 
PCI.  has  been  developed  based  on  a study  of  functions  required  for  process  control, 
and  it  adopts  not  only  a number  of  essential  functions  such  as  structural  description 
of  data,  bit  handling,  decision  table  processing,  virtual  memory  like  data  processing, 
communication  with  operating  system,  . many  powerful  debugging  facilities  and 
powerful  optimizing  methods  to  make  object  codes  shorter.  Consequent Is. 
compared  with  the  conventional  programming  using  assembler  languages,  this 
language  has  brought  about  a remarkable  improvement  in  productivity,  visibility 
uniformity  and  maintenahility  of  software  with  little  sacrifice  on  the  part  of  memory 
capacity  and  running  speed  of  the  object  codes. 


INTRODUCTION 

WITH  the  full-scale  application  of  computes  to  plant 
automation  and  labor-saving  in  industry,  the  amount  of 
programs  required  for  each  application  is  becoming 
enormous.  In  the  field  of  computer  control,  there  is  even 
talk  of  a “software  crisis.” 

A control  program  should  meet  the  following  require- 
ments: 

(1)  To  be  compact,  because  many  computers  are  of 
relatively  small  scale  and  the  main  memory  is  subject 
to  great  restrictions. 

(2)  To  have  a high  execution  efficiency,  as  most 
programs  are  fixed  after  completion  of  a project. 

(3)  Since  many  programs  are  for  logic  decision  process- 
ing, easy  and  accurate  coding  for  such  processing 
should  be  ensured. 

(4)  It  should  permit  easy  and  accurate  coding  for  on-line 
real-time  problems  utilizing  multiprogramming  capa- 
bilities. 

These  requirements  cannot  be  satisfied  by  conventional 
compiler  coding,  so  that  assembler  language  has  been  used 
chiefly.  In  order  to  overcome  the  “software  crisis”,  one  of 
the  best  way  is  to  replace  the  assembler  language  with  a 
higher  level  language  that  has  the  necessary  and  sufficient 
functions,  thereby  improving  the  productivity,  visibility, 
uniformity  and  maintenability  of  software.  Process  con- 
trol language  (PC  L)  we  developed  is  a high-level  language 
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meeting  these  requirements  Its  functions  and  features  will 
be  described. 

POLICY  OF  DEVELOPMENT 
Position  of  PCL 

PCL  holds  a place  at  the  top  of  the  language  processing 
system  of  the  Hitachi  control  computer  500  shown  in  Fig. 
1 . In  the  Hitachi  control  computer  500  language 
processing  system,  the  programming  languages  are  PCL. 
FORTRAN,  and  assembler.  FORTRAN  is  used  for  making 
up  special  calculation  programs  containing  complex 
number,  such  programs  being  very  rare  in  the  control 
field.  The  assembler  language  is  used  for  making  up 
reentrant  subroutines  resident  in  the  main  memory  and 
used  in  common  by  a plurality  of  tasks.  Other  than  these 
special  programs,  most  of  the  control  programs  can  be 
made  up  by  PCL.  The  usage  rates  of  the  three 
programming  languages  are  shown  in  Fig.  2. 

Language  specifications 

In  developing  PCL,  the  language  specifications  were 
determined  according  to  the  following  guidelines 
(1)  It  should  have  sufficient  language  functions  tor 
control  purposes,  without  combined  use  of  assembler 
language.  Some  so-called  control  compiler  languages 
permit  mixed  use  of  assembler  language,  but  this  is 
hard  on  operators  who  are  accustomed  to  compiler 
language.  On  the  other  hand,  this  tends  to  make  those 
accustomed  to  assembler  language  slight  compiler 
language.  At  any  rate,  the  features  of  a higher-level 
language  cannot  be  fully  taken  advantage  of. 
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I Hie  language  system  should  he  such  that  previously 
developed  programs  coded  in  assembler  language  can 
he  effectively  utilized.  Despite  (I  ).  it  is  important 
thai  formerly  made  assembler  coding  programs  he 
effectively  used,  (lenerally,  linkage  of  a subroutine 
made  up  of  assembler  language  involves  a large 
volume  of  work  when  ihe  difference  from  compiler 
language  is  to  be  overcome  by  modifying  the  already 
made  subroutine. 

id  i A Uimdiai  language  system.  Since  FORTRAN  is 
most  widely  used  in  Japan,  the  new  language  system 
should  conform  as  tar  as  possible  to  FORTRAN 
statements. 

(4)  An  easy-to-use  language  system.  In  addition  to 
achieving  i he  required  functions,  the  language  system 
hould  ensure  ease  of  coding  and  use. 

id  i language  system  that  effectively  utilizes  the 
m n i imng  functions  of  an  operating  system 

■ i i the  individual  programs  are  highly 
eltici  n . il  would  be  meaningless  it  the  entire  system 
ad  a poor  oil;  me;  . fherefore,  the  language  system 
should  permit  it.  me  utilization  of  OS  functions, 
above  all,  multiprogramming  functions. 

(t> ) A language  system  that  take-  debugging  into  consider- 
ation. it  is  said  that  debugging  accounts  for  more 
than  half  of  the  work  for  developing  a program,  rims 
the  language  system  should  readily  lend  itself  to 
debugging. 

(7)  A language  system  that  has  reinforced  input/output 
I unctions.  A computer  control  system  uses  numer- 
ous .pecia!  input/output  drv.  vs,  - h as  process  I/O 
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devices  anil  color  cathode  ray  tubes  lliei eioi  un  ss 
efficient  coding  an  be  performed  I t these,  ibe 
language  system  cannot  be  called  satisiaciory  I'm 
process  control. 

Compiler  performance 

factors  for  evaluating  compiler  pertoimance  ate  lit 
time  required  for  compiling.  (J)  si/e  ol  ol'iecl  ud  ill 
executing  time  for  object.  In  PCI  , 1 1 ) and  ( 1 1 a:  given 
priority  over  1 1 ).  Priority  of  111  and  ill  is  del  ci  mined 
differently  in  each  statement,  after  . ureiul  nisi ilicatum 
study 

FEATURES  OF  PCL 

We  analyzed  the  characteristics  of  p ogramming  >1 
process  control  programs,  then  sel  the  target  values  ot 
functions  and  performances.  These  targets  were  attained 
in  PCL.  Therefore,  while  individual  statements  could  -is 
optional  forms,  considering  familiarity  according  . t he 


' 

guidelines,  we  tried  lo  make  lire  coding  formal  as  close  as 
possible  to  that  for  FORTRAN  However,  the  syntax  in 
order  to  realize  the  original  target,  represented  a 
considerable  expansion  from  LOR  IRAN  Major  features 
ot  PCL  will  be  described  in  the  following. 

Features  in  specifications 

Specification  statement  permitting  easy  use  of  integer  type 
data:  In  control  programs,  as  is  seen  in  accumulated  data 
processing,  accumulation  error  and  rounding  error  often 
develop  if  integer  operation  is  not  performed  In  the  case 
1 LOR  I RAN.  data  of  integer  type  by  implicit  type 
specification  are  only  those  alphanumencs  starling  with  I 
J.  k L.  M,  and  N.  For  data  starting  with  other  letters 
siatement  of  integer  type  must  he  made  individually. 

iiising  much  trouble.  In  the  case  of  PCL,  by  setting  an 
IMPLICIT  statement,  the  rule  of  implicit  type  specifica- 
tion can  he  expanded  at  will,  so  that  integer  type 
specification  can  be  made  without  individual  statement. 
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h/t  J Hcmorv  layout  of  data  strnctur. 

I consists  of  the  two  st  is  I , in,:  I h I further  consists  ol  two  sets  ot . I and  K anil 

one  set  of  / level .'  V const i/-  ■ ' " " c ,u  h hu  is  I.  V.  while  I consists  of  two  sets  of 

SI  and  one  i el  of  \ level  In  l<>;.  1 . , . >■<  ,rv  is  formed 
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l-'ig.  4 lilt  dimension  and  hit  data 

. 1 Inis  an  urea  of  20  hits,  Irani  .-1,  / 1 to  .1  '0.  Initial  value  tor  1 • l '■  ’>  lor 

die  /tart  corresponding  to  \(2h  throne!  1 U2.i.  areas  t-r,  ■ .<•. ,/  bm  ■mi  del  /• ./.  «*  that  the  cannot 
he  used 


even  for  alphanumeric^  starting  with  letters  other  than  I 
I.  K.  L,  M,  and  N. 

f sample)  IMPL1CTI  INTEGER  (A  N) 

IMPLICIT  INTEGER*  2(0  \i 
By  the  above  statement,  all  variable  names  and  array 
names  starting  with  any  letter  in  A,  B,  C.  ...  N will  be 
regarded  as  of  ingle  precision  integer  type,  and  all 
variable  names  and  array  names  stalling  with  any  letter  in 
O,  P,  Q.  . X will  be  of  the  double  precision  integer  type, 
so  that  only  those  variable  names  and  array  names  starting 
with  Y or  L will  be  of  the  real  type. 

Conversely  I the  statement  is  made  as  follows:  s 
IMPLICIT  REAL  (A  K) 

variable  names  and  array  names  starting  with  A.  B,  < K 
and  O.  P,  0,  . Z will  be  of  the  real  type,  and  the  only 

variable  names  and  array  names  of  the  integer  type  are 
th  so  starting  v.  ith  L,  M,  or  N. 

Coding  for  hierarchy  data  by  structure  specification. 
Various  tables  usually  consist  of  a number  of  data 
elements,  each  of  which  is  made  up  of  one  or  two  words 
or  several  bits  Each  of  the  data  elements  and  each  of  the 
sets  of  data  elements  are  named,  so  that  reference  cjn  be 
' a H < • via  data  element  name  and  data  set  name  In  this 
wa>  .ding  for  hierarchy  data  by  structure  specification  is 
m ule  . • is  known  as  data  structure  as  in  PL/1, 
vi-  :-de>  11(2), 


conn  i . am!  processing  of  data  ot  several  hits’  length 
(often  seen  in  i iteri  .1  pro  essing  of  program ),  coding  can 
he  made  system  itically  at  tae  same  level  as  ordinary  data 
(Example)  BIT  DIMENSION  A (201 

BIT  DATA  A/101  10101,  12*1; 

In  this  example,  by  BIT  DIMENSION  statement,  array 
element  names  from  A (1)  to  A (20)  are  given  in  uniis  ot 
bits;  and  for  each,  bv  BIT  DA  I A statement,  initial  values 
are  given  so  t hat  All)  will  he  1,  A(2)  will  be  0. 
A(3  >.  ,A(S  ) w I be  I and  A(d  ( . A( 20)  will  be  I . This  is 

illusticted  in  t ig,  4. 

Ei  latcmem  of  Bl  I type  array  there  are  m 

addition  Bl  i COMMON  statement  and  BIT  GLOBAL 
statement.  All  staienients  can  specify  up  to  3rd  dimen- 
sion. 

(Example)  Decision  table  pro.  essing 

■ -,110111]  in  Lie  5 is 

coded  as  in  Fig.  6. 

(E > unple)  Bit  inrg  expression 

Wl’c  \ \ and  N arc  those  in  the  d3ta  structure  of 
Fig.  (, 

Nil  > - A(l  I & X (1.  1)  + N (2) 

ind:  :'es  lliai  on  the  assumption  that  the  result  of  taking 
\\D  in  b is  for  \(  I I 1 and  \t  I . I I is  a positive  integer 
tin  result  ol  adding  \i2l  to  this  positive  integer  i' 


2J  ( 2 ). 

substituted  into 

N(1 ). 

3 A : B I T 

(8). 

Bi i ..trine  expression  is  generally  def 

3X  BIT 

18), 

When  1 ; 

1 1001 1001 1001  loo 

2K  (2), 

J : 

1 1 1 10000 

2L, 

then  1 

00! 1001 1001 100! 1 

3M  (2), 

l&J 

liOOOOOOOl 1000000 

3N, 

1 l.t  : 

! '001 1001 1 1 1 1 100 

above  data  structure  is 

1 % J . 

1 1 oOI 100001 11100 

shown  in  t ig  3. 

Abundant  bit  processing  functions ; ror  processing  of 
1 -hit  data  (represented  by  contacts  and  switches), 
processing  of  decision  tables  irepresen'ed  by  sequence 

f'roi  eii  < iintrol  I , manage 


Statement  for  data  straddling  tasks  In  a control 

compul  i.  usually  a plurality  ot  programs  arc  operated  by 
multitasking  and  an  are,,  for  exchange  of  data  between 
tasks  is  needed,-  .» 
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1 ,i  • 1 \ample  of  coding  for  decision  table  processing 
/ his  h < v a t oiling  of  the  decision  table  in  Dig  * hv  using  Pi  I 
s Input  » shows  that  it  is  held  in  cort  r<  sident  area  b\ 
HM  I .'a  C ondition  Steps  l through  ^ show  that 
■ i •>  tial  data  are  taken  tn  this  task  h\  HI  J DIM b \Sf(>\ 

° and  Dll  lSlO\  DATA  C ill  through  ( > Plies  < inputs 
<d  ■ ">  litmus  are  cheeked  h\  /)/■(  ISIO\  ID  statement  indicate  d 
latrmrnt  number  il  l \)  /() 


Dig  7 Concept  of  virtual  mentors  span 

Data  can  he  processed  without  distinguishing  mem  menhirs  and 
auxiliary  memory , hut  h\  regarding  the  whole  as  a singlt  memory 
virtual  manors  space 
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Hv  adding  data  III  in  core  resident  area  and  data  Mfl)  in 
auxiliary  memory,  the  program  to  he  accommodated  in  area 
k i the  task  can  he  written  as  K(! I I tl)+M(l),  so  that  then 
is  no  need  to  think  of  the  data  location  in  the  expression. 


This  area  is  usually  secured  in  the  resident  area  on  the 
main  memory  or  on  the  auxiliary  memory.  Heretolore. 
reference  to  this  area  has  been  made  by  absolute 
addressing  (assembler),  or  reference  has  been  impossible 
(TOR  I RAN).  In  PCI  . it  suffice:  to  state  the  required  area 
.1  , .1  variable  name  or  an  array  name . assignment  10  the  main 
memory  or  the  auxiliary  memory  is  done  automatically 
by  a loader  ( Tig.  1 ). 

<T.xample>  GLOBAL  Statement 

BIT  GLOBAL  statement 

Tor  these,  data  areas  are  secured  in  the  residence 
section  of  the  main  memory. 

BULK  statement 

For  this,  data  areas  are  secured  on  the  auxiliary 
memory . 

Data  with  a concept  of  virtual  memory . Tven  when  a 
systems  engineer  or  a plant  engineer,  to  say  nothing  of 
specialist  in  programming,  is  making  up  a program,  he  will 
not  have  to  be  especially  conscious  of  data  on  the 
auxiliary  memory  (drum  memory)  and  can  handle  them 
directly  within  various  statements  in  the  same  manner  as 
data  on  the  main  memory  (core  memory).  Tig  7 
illustrates  the  concept  of  virtual  memory  space  adopted  in 
PCL.  and  Tig.  8 an  example  of  coding  using  virtual 


memory  data  space 

Incorporation  of  system  communication  statement 
Generally  m an  on-line  real-time  control  system,  in  order 
to  effect  synchronization  of  (he  various  tasks  being 
operated  independently,  it  is  necessary  to  stop,  operate, 
or  temporarily  slop  certain  (asks,  and  to  prevent  illegal 
sequence  of  data  read, write  or  deadlock  for  resources 
used  in  common  by  carious  tasks,  exchange  of  signals  for 
this  is  all  conducted  cia  OS  control  instructions. 

In  PCL,  (he  fun  non  of  OS  control  instruction  is 
incorporated  as  system  communication  statements. 

T ample)  QULUT  statement,  START  statement, 

STOP  statement, 

WAIT  statement,  Rl  STRVT  statement. 

TRLT  statement. 

Abundant  and  expandable  I/O  functions:  Tor  color  C Rl 
and  process  I/O  devices  (e  g.  AI,  01,  AO,  DO),  as  well  as 
general  I/O  devices  (e.g.  L/P.  C/R.  PTR,  FTP),  coding  can 
be  made  in  ihe  same  statement  and  in  the  same  concept. 
Moreover,  consideration  is  given  so  that  (he  peculiarities 
of  individual  I/O  devices  do  nol  appear  in  the  language. 

Tig.  u is  an  example  of  coding  for  color  CR  I display.  If 
tic  "70”  in  the  WRITT  statement  in  Tig.  V is  the  file- 
reference  number  for  color  OR  I display  , then,  by 
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Tig.  v /-.  sample  of  coding  for  color  CR  T display. 

If  "70“  in  WRITE  statement  indicates  color  CR  T display,  then  hy 
execution  of  the  program,  the  value  of  K 1 000)  is  indicated  in  red 
in  integer  type  5 digits. 


executing  this  program,  the  value  of  K(  1 000  ) is  displayed 
in  red  in  an  integer  type  five-digit  numeral. 

Ease  of  linkage  with  existing  programs  of  assembler 
coding:  Comparison  of  the  argument  processing  systems 
of  a subroutine  made  up  of  assembler  language  and  one 
made  up  of  compiler  language  shows  that  in  the  former 
usually  the  argument  value  itself  is  set  but  in  the  latter  the 
argument  value  itself  is  not  set  but  rather  the  address 
where  the  argument  value  is  accommodated  is  set. 
1 herefnre.  successful  linkage  cannot  be  effected  by  calling 
an  assembler-language  subroutine  as  it  is  from  a compiler- 
language  program,  so  that  usually  the  assembler-coding 
subroutine  has  to  be  changed 

With  PCX.  processing  is  possible  for  any  linkage 
system,  so  that  no  revision  is  required  even  when  an 
assembler-language  subroutine  is  to  be  called  from  a 
compiler-language  program. 

(Example)  CAL  L SUB  (A,  10) 

CALL  SUB < a A.  a 10) 

When  there  is  the  a mark  in  front  of  the  argument, 
the  usual  compiler  argument  processing  is  not  made,  but 
i.ither  the  argument  processing  method  usually  employed 
in  assembler  language  is  used. 

Abundant  debugging  functions  In  addition  to  dump  and 
trace  functions,  PCX  has  the  compile  made  specification 
function  to  make  switching  between  statements  for 
off-line  i r<  essing  and  on-line  processing,  the  function  to 
witch  the  subroutine  used,  and  the  overflow  check 
i eti  m for  attay  subscripts.  Several  hundred  error 
a.  tag’s  are  provided  for  use  at  compiling  and  execution. 
(Example)  DEBUG  VALUES  statement 

When  specified  values  arc  given  to  variables  and  arrays 
within  the  range  of  the  specified  statement  numbers,  the 


' Ur  dUG  fjACI  l i i I 1 

DM. Pi  L[  M ,i> 

cW;.  v j;. 

* 

GlOBial  ciiufl; 

, M ( i 0 C / , M 

f DEBdii!  VALUES 

1 .100 

X debug  subscrip 

T L.M 

* 1 CONTINUE 

do  ;;oo  i = i, n 

i 0 0 L(  ill  M ( 1 ) t N 

Si  WRITE!  fe,200)  L 

X 200  FORMAT!  1 H , .’01 

5 ) 

5 TOPI 

END  1 

s' 



Tig.  10  Example  of  usage  of  compile  mode  * 

Since  compile  mode  is  hy  * specif  ication,  statements  m which  tin 
first  column  is  7 are  treated  as  notes. 


variable  names  and  array  element  names  as  well  as  the 
values  substituted  into  them  are  printed  out  by  L/P. 

DEBUG  LX.OW  statement 

When  a GOTO  statement,  arithmetic  IE  statement,  or 
RETURN  statement  has  been  executed  within  the 
specified  range  of  statement  numbers,  the  shift  of  control 
is  printed  out. 

DEBUG  SUBSCRIPT  statement 

When  in  a specified  array,  the  subscript  of  an  array 
element  name  is  larger  than  the  stated  value,  printing  is 
made  to  that  effect. 

COMPILE  MODE  statement 

An  example  of  usage  of  complie  mode  statements  is 
given  in  Fig.  10.  In  this  statement.  WRITE  statements  and 
FORMAT  statements  are  processed  as  footnotes  If  in  Fig 
10  the  COMPILE  MODE  is  specified  by  i . then  the  result 
of  compilation  will  be  as  presented  in  Fig.  1 1 . 

RENAME  statement 

An  example  of  usage  of  this  line  expression  will  he 
given  below 

RENAME  (FETCH,  DUMP) 

( Al  l FETCH  (A.  B,  C) 

In  this  example,  CALL  FETCH  (A.  B.  C)  will  be 
executed  as  CALL  DltMP  (A  B,  Cl. 

Features  in  performances 

Efficient  object  taking  advantage  of  16  bit  machine:  A 
16-bit  machine  usually  has  I -word  instructions  (lb-bit 
instructions)  and  2-word  instructions  ( 32-bit  instruc- 
tions) In  PCL,  I -word  instructions  are  used  as  far  as 
possible,  as  a result  of  which  efficient  objects  arc  lormed 
It  is  in  this  respect  that  conventional  compiler  programs 
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Fig.  / / Example  of  compilation  by  compile  mode  % 

The  program  in  Fig.  10  is  compiled  by  specifying  the  compiler 
mode  as  I il  statements  with  * in  the  first  column  arc  neglected 


for  16-bit  machines  are  said  to  provide  less  efficient 
objects  than  programs  in  assembler  language.  In  PCL.  this 
problem  is  resolved,  and  efficiency  is  vastly  improved. 
Object  aimed  at  efficient  utilization  of  auxiliary  memory: 
Areas  defined  by  variable  names  and  array  names, 
except  those  where  the  initial  values  are  set  by  DATA 
stetements,  are  all  work  areas  where  the  values  are 
accommodated  at  execution,  so  that  it  suffices  to  secure 
the  areas  at  program  roll-tn  from  auxiliary  memory  to 
main  memory  for  execution.  In  conventional  compiler 
language,  thought  is  given  only  to  moving  the  program  in 
the  main  memory,  with  the  result  that,  when  an  object 
formed  is  stored  on  auxiliary  memory  as  an  object  for 
multiprogramming,  work  areas  corresponding  to  the  varia- 
bles and  arrays  are  secured  also  on  the  auxiliary  memory. 
Dus  is  one  cause  of  increasing  the  capacity  of  auxiliary 
memory.  This  problem  is  solved  in  PCL. 

Common  subordinate  program:  In  conventional  compiler 
objects,  subordinate  programs  (e.g.  READ/WRITE  pro- 
ces  Tug  program  at  execution,  type  change  program, 
various  function  modules)  follow  each  main  program. 
Generally,  for  two  or  more  main  programs  (tasks  in  PCL) 
that  are  used  in  common,  by  making  them  reside  in  tile 
main  memory,  the  size  of  individual  programs  on  Ihe  main 
memory  and  auxiliary  memory  can  be  vastly  reduced.  In 
PCI-,  therefore,  all  the  subordinate  programs  made 
automatically  in  compiler  language  are  provided  in 
reentrant  form,  so  that  they  can  easily  be  made  resident  in 
the  main  memory  and  can  be  used  simultaneously  in  two 
or  more  tasks. 

Subordinate  program  of  order  reentry  system:  A number 
of  subordinate  programs  are  provided  for  a single 


function  Lor  instance,  there  are  two  kinds  of  programs 
(same  link  name)  which  have  identical  functions,  but  one 
has  a large  number  of  words  but  shorter  execution  time, 
and  the  oilier  has  a smaller  number  of  words  but  a longer 
execution  time  A user  that  employs  the  function  at  a 
high  frequency  may  adopt  the  former  program,  while  a 
user  that  employs  it  at  a low  frequency  may  adopt  the 
latter  program 

Making  I/O  processing  programs  into  tasks  I/O  processing 
programs  in  conventional  compiler  language  con.titute 
subordinate  subroutines  for  I/O  format  and  parallel 
element  processing,  this  is  devoid  of  the  con  ept  of 
multiprogramming  in  which  parallel  processing  .s  made  by 
CPU  and  I/O  devices 

With  PCL,  this  point  is  solved  by  making  I/O 
processing  programs  an  independent  task  Also,  the 
programs  are  made  available  for  common  use  by  a 
plurality  of  tasks  without  making  them  resident  in  the 
memory  Further,  by  buffering  the  exchange  of  I/O  data, 
temporary  high-traffic  processing  demand  on  low-speed 
I/O  devices  is  smoothed 

Other  optimization  techniques  In  addition  to  above- 
mentioned  techniques,  various  techniques  for  optimiza- 
tion at  the  statement  level  are  adopted  in  order  to 
minimize  execution  time  and  memory  space.  These 
techniques  include  optimization  of  DO  LOOP,  optimiza- 
tion of  array  subscript  calculation,  optimization  of  arith- 
metic II-  statements,  and  optimization  of  GOTO  state- 
ments. 

By  adopting  the  various  optimization  techniques 
described  above  it  has  been  confirmed  that  fot  ma... 
routines  of  individual  programs,  they  are  equal  to  or  10'," 
larger  than  an  assembler  coding  program  made  by  an 
extremely  c:  perienced  programmer  and  for  a whole 
computer  system  including  subordinate  programs  and  OS. 
the  memory  size  is  about  1 O' I larger  than  in  cases  where 
assembler  language  is  used.  Furthermore,  if  a program  is 
made  by  a normally  experienced  programmer,  the  pro 
gram  size  by  PCI  is  often  equal  or  even  less  in  some  cases. 

CONCLUSIONS 

With  regard  to  the  process  control  compiler  language 
PCL  developed  for  the  Hitachi  control  computer  500,  the 
guidelines  lor  development,  and  features  in  language 
specifications  and  performances  have  been  described 

Heretofore,  programs  for  process  control  or  on-line 
processing  have  automatically  meant  assembler  coding 
Drograms.  The  authors  see  the  PCI  will  open  the  way  for 
extensive  use  of  higher  level  languages  in  process  control 
and  on-line  real-time  processing. 

At  present  PCL  is  designed  for  use  with  the  Hitachi 
control  computer  500,  but  work  ts  under  way  to  make  it 
applicable  to  computer  systems  of  the  Hitachi  control 
computer  series.  They  are  Hitachi  control  computer  150, 
350  and  700. 

Die  authors  express  their  thanks  to  those  who  have 
cooperated  in  the  development  work. 
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